xiaoshua / junixsocket Goto Github PK

Hi.

Please add additional way to specify for JVM where to locate the native 
library, by setting the LD_LIBRARY_PATH parameter.

Thanks!

Introduction :

Before explaining this issue, i would like to thank the author for this work.

I'm planning using junixsocket to communicate with nodeJs by a better way
(in term of performance) than TCP socket.

The problem : 

I'm using InputStream.available() for my needs.
The commons-apache-io use this function too with IOUtils.xxx()

But this function isn't implemented.

What steps will reproduce the problem?

-> socket.getInputStream().available()

What is the expected output? What do you see instead?

-> The expected output must return the amount of available bytes from socket.

What version of the product are you using? On what operating system?

-> All

Please provide any additional information below.

-> You should see ioctl.h to get an idea to implement this function.

Jean-Vincent LEROY

What steps will reproduce the problem?
1.Can it be used for multithreading?
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
1.3

Please provide any additional information below.

Hi.

I'm getting the error below:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no
junixsocket-linux-1.5-amd64 in java.library.path
            at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709)
            at java.lang.Runtime.loadLibrary0(Runtime.java:823)
            at java.lang.System.loadLibrary(System.java:1028)
            at
org.newsclub.net.unix.NativeUnixSocket.<clinit>(NativeUnixSocket.java:73)
            at
org.newsclub.net.unix.AFUNIXServerSocket.<init>(AFUNIXServerSocket.java:49)
            at
org.newsclub.net.unix.AFUNIXServerSocket.newInstance(AFUNIXServerSocket.java:62)
            at
neo.helper.tests.junixSocketServer.main(junixSocketServer.java:17)

I think I tried every jar. Still this error on: 

AFUNIXServerSocket server = AFUNIXServerSocket.newInstance();


Thanks.

Can you add includeantruntime="false" to <javac> tasks in order to suppress the 
following warning issued by ANT 1.8:

warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds

Best Regards.
Eric.

Would be really convenient if this library is added (and kept up to date with 
each release) on a maven repository, as recommended here: 
http://code.google.com/p/google-maven-repository/wiki/WhereIsMyFavoriteGooglePro
ject

cheers.

What steps will reproduce the problem?
1. Create a unix domain socket (as a Server application)
2. Read data from unix domain socket with BufferedReader.readLine() 
3. Client side closes connection
4. IOException will occur 'Underlying input stream returned zero bytes'

What is the expected output? What do you see instead?
No IOException when client closes connection. Data is transferred successful 
but close is not 
handled correct. Should behave like TCP/IP socket.

What version of the product are you using? On what operating system?
Version 1.1 on Mac OS X 10.6 (java version "1.6.0_17"), problem also exists on 
Debian.

Please provide any additional information below.
I am using the same code with a TCP/IP socket and it works great but with 
junixsocket i am 
getting an IOException when the connection is closed on the client side. It is 
not a big issue 
because the data transfers is correct. On the client side I am using PHP with 
fread and 
fsockopen. Based on the information I did find on this exception it has 
something to do with the 
-1 status code.

Example Java code:
// Read while no more data is send aka null
while( (inputLine = in.readLine()) != null){
    // Parse input based on communication protocol and send result to client
    result = parseResult(inputLine);
    out.write(result[0]);
    out.flush();

    // Close connection if requested
    if(result[1]){
        socket.close();
    }
}

Stack trace
sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:268)
sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
java.io.InputStreamReader.read(InputStreamReader.java:167)
java.io.BufferedReader.fill(BufferedReader.java:136)
java.io.BufferedReader.readLine(BufferedReader.java:299)
java.io.BufferedReader.readLine(BufferedReader.java:362)
myproject.ServerThread.run(ServerThread.java:54)

"java.io.IOException: Underlying input stream returned zero bytes"

Would be great if you could look in to this problem and thanks for this great 
project!

The ServerSocket JavaDocs state that 

"Closes this socket. Any thread currently blocked in accept() will throw a 
SocketException."

However, the junixsocket implementation of accept() does seem to implement this 
behavior.

Hi.

Is it possible to cancel the waiting accept() request (by interrupting the 
Thread)?

If not, this would be a valuable addition.

Thanks!

Is this a bug, or is this a desired behaviour? 
In AFUNIXSocketImpl.setOption send and receive buffers expect boolean as the 
parameter.
I am trying to plug this library into a piece of code that was written to deal 
with inet sockets, but it throws an exception in this place since the code is 
doing setReceiveBufferSize on a socket giving an integer as the value.

A recent Oracle security patch to Java changes the internal implementation of 
java.net.InetSocketAddress, and eliminates the port field. This prevents 
junixsocket RMI from instantiating.

https://bugzilla.redhat.com/show_bug.cgi?id=907456
http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html
change to InetSocketAddress: 
http://icedtea.classpath.org/hg/release/icedtea7-forest-2.3/jdk/rev/ab011765c4e8


What steps will reproduce the problem?
1. Install latest java on RHEL/CentOS 6.x
2. Instantiate a unix socket RMI server


What is the expected output? What do you see instead?

        org.newsclub.net.unix.AFUNIXSocketException: Cannot find field "port" in java.net.InetSocketAddress. Unsupported JVM?


What version of the product are you using? On what operating system?

junixsocket 1.3

CentOS release 6.2 (Final)

java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.6) (rhel-1.54.1.11.6.el6_3-x86_64)



Please provide any additional information below.

shutdownInput() and shutdownOutput() are not implemented in
AFUNIXSocketImpl, causing exceptions. The attached simple patch adds the
implementations.

What steps will reproduce the problem?
1.gives compiler error while building if using a cross platform gcc
compiler(ppc) as jni.h and jni_md.h cannot be located  
[echo] Compiling for architecture i386 on Linux
     [exec] In file included from
./src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c:19:
     [exec]
./src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.h:2:17:
jni.h: No such file or directory
     [exec] In file included from
./src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c:19:
     [exec]
./src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.h:15:
error: syntax error before "void"
     [exec]
./src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.h:16:
error: parse error before '*' token
     [exec]
./src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.h:16:
warning: type defaults to `int' in declaration of
`Java_org_newsclub_net_unix_NativeUnixSocket_bind'


2.
3.

What is the expected output? What do you see instead?
Should be able to locate jni header files.

What version of the product are you using? On what operating system?
junixsocket-1.1-src.tar.bz2

Please provide any additional information below.

i ported the build.xml to use our platform specific gcc compiler which is
i686-linux-gcc 3.4.4 . After i did that i started to get errors.

I fixed this by correcting a typo in the build.xml here is a small diff 

--- junixsocket-1.1.orig/build.xml
+++ junixsocket-1.1/build.xml
@@ -18,7 +18,7 @@
 <project name="junixsocket" default="dist" basedir=".">

     <property environment="env"/>
-    <property name="jdk.home=" value="${env.JAVA_HOME}" />
+    <property name="jdk.home" value="${env.JAVA_HOME}" />

     <property name="app.name" value="junixsocket" />
     <property name="app.title" value="junixsocket library" />

This is not really a bug, more like a question, but I couldn't figure out 
where else to submit it. Can accept() on a AF_LOCAL socket return 
ECONNABORTED? It would seem that no, but I couldn't find it specified 
either way anywhere.

The patch below handles ECONNABORTED in a way consistent with the rest of 
the Java sockets, but I am not sure it is necessary. But may be it is 
better to be safe than sorry?

regards,
Tzvetan

diff --git 
a/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c 
b/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c
index 05d7363..9cb0a20 100644
--- 
a/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c
+++ 
b/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c
@@ -101,7 +101,11 @@ extern "C" {
 #endif
                ;

-               int socketHandle = accept(serverHandle, (struct sockaddr 
*)&su, &suLength);
+               int socketHandle;
+               do {
+                       socketHandle = accept(serverHandle, (struct 
sockaddr *)&su, &suLength);
+               } while(socketHandle == -1 && errno == ECONNABORTED);
+
                if(socketHandle == -1) {

org_newsclub_net_unix_NativeUnixSocket_throwException(env, strerror(errno), 
file);
                        return;

Once I create a new socket, and close it either via the destructor, or via 
the close() function, the object destroyed but the underlying native 
socket is kept open.

This causes the app to hit the "too many open files" limit on Linux, and 
severaly impacts it's operation.

Attached is a repro-case.


I'm checking the amount of used sockets via the:
ls /proc/ID/fd | wc -l - where ID  is the id of the process.

Any idea?

I have a use-case where the automatic unlink of the socket on close is 
undesirable.  I would request a flag or mode that disables the unlinking.

My use case is atomically taking over from an existing server by binding a new 
socket, then renaming that socket to the existing socket.  This is very useful 
for server restarts without dropping any connections.  But it is defeated if 
junixsocket tries to unlink its socket, because it in fact unlinks the new 
socket!

Add support for the SO_PEERCRED socket option
(see http://www.welz.org.za/notes/on-peer-cred.html)

This option would be very useful for providing local user authentication 
support.


It looks like this could easily be added and accessed through the 
AFUNIXSocketImpl.getOption method.

Would need to provide some java class to hold the ucred struct data, and 
populate it in the native code, but that should be fairly simple.

I might spend some time on this and contribute a patch.
If you have any thoughts, let me know.

Attached is a patch for FreeBSD. Feel free to include this in the next 
release. It has been tested on FreeBSD 8.0, with both i386 and amd64, using 
Java 1.6. Run "ant -Djdk.home=/usr/local/jdk1.6.0" to build (change version 
as necessary). Requires java/jdk port to be installed.

Thanks,
Jason

What steps will reproduce the problem?
1. Attempt to build on a 32bit linux arch.
2.
3.

What is the expected output? What do you see instead?

Expect to have the 32bit linux distribution built.  Instead the build fails 
because it tries to build both 32bit and 64bit, and it is unable to build the 
64bit version.

What version of the product are you using? On what operating system?

$ uname -srm  
Linux 2.6.24-24-generic i686

Please, test offset+length against array bounds in read/write native functions 
to avoid memory corruption in presence of wrong arguments values.

Patch provided in attachment.

Best regards,
Eric.

What steps will reproduce the problem?
code:
    File socketFile = new File("/tmp/cgi.socket");
    AFUNIXSocket sock = AFUNIXSocket.newInstance();
    sock.connect(new AFUNIXSocketAddress(socketFile));
    sock.setSoTimeout(12000);
    sock.close();

output:
org.newsclub.net.unix.AFUNIXSocketException: Protocol not available
    at org.newsclub.net.unix.NativeUnixSocket.setSocketOptionInt(Native Method)
    at org.newsclub.net.unix.AFUNIXSocketImpl.setOption(AFUNIXSocketImpl.java:319)
    at java.net.Socket.setSoTimeout(Socket.java:1003)


is there any solution? thanks~~

What steps will reproduce the problem?
1. Attempt to connect to a non existing unix socket
2. let the java application running
3.



What is the expected output? What do you see instead?

run 'lsof -U' as root. This should not list any unix socket (file handle)
allocated by the java process however it does. All new failed connect
attempt allocates a new socket which will only be released when the java
application terminates. This may result in 'too many open files' error
messages in any applications running on the same computer

check lsof -U output as root - there is a socket/file handle allocated for
the java process thought the connection fails 



What version of the product are you using? On what operating system?

junixsocket 1.1 - linux (Debian, RedHat, several gcc versions)



Please provide any additional information below.

The fix is easy: if connect() returns error release the socket before
throwing the exception. See the patch file below.


*** org_newsclub_net_unix_NativeUnixSocket.c  2009-08-28 20:24:29.000000000
+0200
--- org_newsclub_net_unix_NativeUnixSocket.c    2010-02-09
09:54:02.000000000 +0100
***************
*** 227,232 ****
--- 227,233 ----

                int ret = connect(socketHandle, (struct sockaddr *)&su,
suLength);
                if(ret == -1) {
+                       close( socketHandle );

org_newsclub_net_unix_NativeUnixSocket_throwException(env, strerror(errno),
file);
                        return;
                }

What steps will reproduce the problem?
1.m_serverSocket = AFUNIXServerSocket.newInstance();
2.m_serverSocket.bind(new AFUNIXSocketAddress(socketFile));
3.m_serverSocket.setSoTimeout(30 * 1000); // timeout for 30 seconds
4. In run(), call m_serverSocket.accept() in a try/catch. Catch 
SocketTimeoutException to print debug and continue...

What is the expected output? What do you see instead?
Expect to see a ServerTimeoutException, as specified in java.net.ServerSocket. 
Since this class extends ServerSocket, and no mention of different behavior is 
specified, would expect same behavior as documented in super class.

Instead:
org.newsclub.net.unix.AFUNIXSocketException: Resource temporarily unavailable 
(socket: <path to socket>)
        at org.newsclub.net.unix.NativeUnixSocket.accept(Native Method)
        at org.newsclub.net.unix.AFUNIXSocketImpl.accept(AFUNIXSocketImpl.java:58)
        at org.newsclub.net.unix.AFUNIXServerSocket.accept(AFUNIXServerSocket.java:104)

What version of the product are you using? On what operating system?
1.3

Please provide any additional information below.

What steps will reproduce the problem?
1. Make a getSendBufferSize call on a connected AFUNIXSocket. On Linux, an
AFUNIXSocketException is thrown with message "Protocol not available".
2.
3.

What is the expected output? What do you see instead?
I would expect to get the buffer size.

What version of the product are you using? On what operating system?
1.2, RedHat Enterprise Linux 4

Please provide any additional information below.

I believe the problem is in how values are mapped in
AFUNIXSocketImpl.getOption(optID) and AFUNIXSocketImpl.setOption(optID,
value). The optID's in this context seem to be referring to SocketOption
constants values, but when I look at the C code for
Java_org_newsclub_net_unix_NativeUnixSocket_getSocketOptionInt and
Java_org_newsclub_net_unix_NativeUnixSocket_setSocketOptionInt, it is
referring to optIDs of the same name in C (e.g., SO_LINGER) which do NOT
correspond to the C values found in socket.h. For instance, on my system
SocketOptions.SO_LINGER = 128, but SO_LINGER in socket.h is 13.

Consequently most of the Java-level socket manipulation options not only
aren't implemented (not a big deal), but actually implement undefined behavior.

As a further complicating factor, the source code for
AFUNIXSocketImpl.setOption treats the SocketOptions.SO_RCVBUF and
SocketOptions.SO_SNDBUF cases as booleans; note the "expectBoolean" call. I
don't think this is right either, though it doesn't matter until the other
problem is addressed as well...

I ran into the exact same problem as described here...
http://stackoverflow.com/questions/2697745/on-linux-what-can-cause-dlopen-to-emi
t-sigfpe


And fixed it the same way as described on that link.

i.e by adding 
<arg value="-Wl,--hash-style=both" />

to the gcc-linux.arch ant target


(See attached patch)

AFUNIXSocketImpl.connect() ignores the timeout parameter. Ideally it should
implement it by putting the socket in non-blocking mode and waiting, or at
least it should throw an error if a timeout is specified, but is not supported.

I will attach a patch for the former when I have time.