Trying to deploy Wildfly in OSv

[dominique...@gmail.com]

Hello!

I'm trying to deploy Wildfly in OSv. I was wondering if someone else is trying the same thing and if we could pool resources.

Also I ran into a couple of issues:

1. JBoss requires that its own LogManager be configured as the JVM log manager which conflicts with the LogManager wrapper OSv uses. I might have a workaround for this one. See http://lists.jboss.org/pipermail/wildfly-dev/2016-February/004796.html for details
2. JBoss tries to write to its configuration files, I get an error:

Caused by: java.io.IOException: Invalid argument
at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1072)
at java.nio.channels.FileChannel.lock(FileChannel.java:1053)
at org.jboss.as.logging.logmanager.ConfigurationPersistence.writeConfiguration(ConfigurationPersistence.java:405)

My understanding is that by default, the filesystem is RW, so I guess the error is related to the lock0 method. The issue is easy to reproduce without wildfly. I just modified the java example with the following code:

package io.osv;

import java.io.FileOutputStream;
import java.nio.channels.FileLock;

public class Main {
public static void main(String[] args) throws Exception {

FileOutputStream out = new FileOutputStream("/config.txt");
final FileLock lock = out.getChannel().lock();
[...]

This will produce the following exception when run:

io.osv.ContextFailedException: java.io.IOException: Invalid argument
at io.osv.Context.join(Context.java:63)
at io.osv.ContextIsolator.runSync(ContextIsolator.java:146)
at io.osv.RunJava.main(RunJava.java:35)
Caused by: java.io.IOException: Invalid argument
at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1021)
at java.nio.channels.FileChannel.lock(FileChannel.java:1052)
at io.osv.Main.main(Main.java:11)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at io.osv.ContextIsolator.runMain(ContextIsolator.java:233)
at io.osv.ContextIsolator.access$400(ContextIsolator.java:32)
at io.osv.ContextIsolator$3.run(ContextIsolator.java:118)

The actual code for the lock0 method should look like :

http://hg.openjdk.ja
va.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/solaris/native/sun/nio/ch/FileDispatcherImpl.c#l175

I'm not familiar enough with the native parts of OSv to go any further. Could somebody more knowledgeable about the FS part help me debug this one ?

Best regards,
Dominique

[jiv...@gmail.com]

Hi Dominique

I also encountered the same issue in channel lock.
Did you find a way get past this issue ?

Thanks
Jivjot

[Nadav Har'El]

On Sun, Feb 28, 2016 at 1:15 PM, <dominique...@gmail.com> wrote:

Hello!

I'm trying to deploy Wildfly in OSv. I was wondering if someone else is trying the same thing and if we could pool resources.

Also I ran into a couple of issues:

1. JBoss requires that its own LogManager be configured as the JVM log manager which conflicts with the LogManager wrapper OSv uses. I might have a workaround for this one. See http://lists.jboss.org/pipermail/wildfly-dev/2016-February/004796.html for details

Tomek (CC'ed) is the expert on the logger wrapping we're doing, why, and how to avoid and/or use it correctly. Tomek?

 

2. JBoss tries to write to its configuration files, I get an error:

Caused by: java.io.IOException: Invalid argument
        at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)

I think this is a dup of https://github.com/cloudius-systems/osv/issues/185 and I updated the issue to also include the additional information you provided now.

However, there is something I really don't understand maybe you can help me figure this out.

sun.nio.ch.FileDispatcherImpl.lock0() clearly uses fcntl(F_SETLK, ...) as I saw in its source code.

But what our fcntl(F_SETLK) does is to print a message once ("WARNING: fcntl(F_SETLK) stubbed") and succeed.

So lock0() should not have failed with EINVAL, as it appears to be doing.

Can you please run verbose (run.py -V) and see if you get a message like "unsupported fcntl cmd 0x...", or some other message before the failure?