«

Hello all,

I'm facing a mind-boggling problem with JNI on Linux. I will be giving
too little details for anyone to come up with a solution: fact is, the
context is really too complex. I'm mostly looking for hints rather
than a solution.

I have developed a Java class "UnixSocket" with native methods to
support using Unix-domain sockets from Java applications. The native
methods are in a shared library (.so) and they call C functions from
another shared library. The latter is part of the "platform layer" of
the product I am working on, and it is used by several other clients,
including several C processes. There's one version for True64 and one
for Linux, and both work with all of their C clients (AFAIK).

Now, the Java applications that use UnixSocket on True64 work right.
Under Linux, on the other hand, the send() method fails. This
indirectly calls OS' sendmsg(), which returns -1 with errno set no
ENOBUF (55). In fact, the C function that calls sendmsg() makes
several retries, but all fail in the same way (55).

These Java applications are multi-threaded, Java is:

java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition
Classic VM (build 1.3.1-1, native threads, jit)

I should also note, that this problem seems to depend on the specific
build. We use two different make-compile machineries (as I said, the
context is complex, so I don't even know all the details), and one of
them produces a library that works, the other produces one that
doesn't work, from the same source code. I am investigating about the
actual differences between these two machineries, but I still
desperately need any hint.

Thanks in advance
MC

moongateclimber a écrit:
> Hello all,
>
> I'm facing a mind-boggling problem with JNI on Linux. I will be giving
> too little details for anyone to come up with a solution: fact is, the
> context is really too complex. I'm mostly looking for hints rather
> than a solution.
>
> I have developed a Java class "UnixSocket" with native methods to
> support using Unix-domain sockets from Java applications. The native
> methods are in a shared library (.so) and they call C functions from
> another shared library. The latter is part of the "platform layer" of
> the product I am working on, and it is used by several other clients,
> including several C processes. There's one version for True64 and one
> for Linux, and both work with all of their C clients (AFAIK).
>
> Now, the Java applications that use UnixSocket on True64 work right.
> Under Linux, on the other hand, the send() method fails. This
> indirectly calls OS' sendmsg(), which returns -1 with errno set no
> ENOBUF (55). In fact, the C function that calls sendmsg() makes
> several retries, but all fail in the same way (55).
>
> These Java applications are multi-threaded, Java is:
>
> java version "1.3.1"
> Java(TM) 2 Runtime Environment, Standard Edition
> Classic VM (build 1.3.1-1, native threads, jit)
>
> I should also note, that this problem seems to depend on the specific
> build. We use two different make-compile machineries (as I said, the
> context is complex, so I don't even know all the details), and one of
> them produces a library that works, the other produces one that
> doesn't work, from the same source code. I am investigating about the
> actual differences between these two machineries, but I still
> desperately need any hint.
>
> Thanks in advance
> MC

Are sure that the LD_LIBRARY_PATH are the same with the two
"make-compile machineries" ?
Have you take a look to jpcap project
http://netresearch.ics.uci.edu/kfujii/jpcap/doc/ ?

Clearly it's difficult to post a precise response because there's no precise
question but I would advise you to visit the JSocket Wrench site at
http://jswrench.sourceforge.net, which addresses several of the issues
involved with cross-platform calls to the Berkley sockets library from the
JNI. Please check-out the source from CVS because the current baseline is
now quite different to the most recent stable release. (A new stable release
will appear soon).

Please consider a prompt upgrade to JDK1.4 - java.net.InetAddress has
divided into IPv4 and IPv6 versions so you might as well face the pain
sooner rather than later.

HTH,

rubylips

"moongateclimber" <> wrote in message
news: om...
> Hello all,
>
> I'm facing a mind-boggling problem with JNI on Linux. I will be giving
> too little details for anyone to come up with a solution: fact is, the
> context is really too complex. I'm mostly looking for hints rather
> than a solution.
>
> I have developed a Java class "UnixSocket" with native methods to
> support using Unix-domain sockets from Java applications. The native
> methods are in a shared library (.so) and they call C functions from
> another shared library. The latter is part of the "platform layer" of
> the product I am working on, and it is used by several other clients,
> including several C processes. There's one version for True64 and one
> for Linux, and both work with all of their C clients (AFAIK).
>
> Now, the Java applications that use UnixSocket on True64 work right.
> Under Linux, on the other hand, the send() method fails. This
> indirectly calls OS' sendmsg(), which returns -1 with errno set no
> ENOBUF (55). In fact, the C function that calls sendmsg() makes
> several retries, but all fail in the same way (55).
>
> These Java applications are multi-threaded, Java is:
>
> java version "1.3.1"
> Java(TM) 2 Runtime Environment, Standard Edition
> Classic VM (build 1.3.1-1, native threads, jit)
>
> I should also note, that this problem seems to depend on the specific
> build. We use two different make-compile machineries (as I said, the
> context is complex, so I don't even know all the details), and one of
> them produces a library that works, the other produces one that
> doesn't work, from the same source code. I am investigating about the
> actual differences between these two machineries, but I still
> desperately need any hint.
>
> Thanks in advance
> MC

I forgot to thank the two posters who replied to my message. The
problem turned out to be a pure C problem, a type mistake involving
undefined behavior (hence the different behavior with different
builds). Anyway, I had a look at the sources mentioned in the replies,
found them very interesting and bookmarked them, so it wasn't in vain.

Thanks for your time,

MC