Socket Accept failure

Hi,
I am running 4.5.1 SP13. I have a startup class which registers itself as an RMI observer with a remote server. It initially connects, and receives the first message.
Not long after receiving the first message, the following is output numerous times before the server shuts itself down:
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> Listen failed. Failure count: 1
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> java.net.SocketException: socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:413)
at java.net.ServerSocket.implAccept(ServerSocket.java:241)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at weblogic.t3.srvr.ListenThread.run(ListenThread.java:280)
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> Attempting to close and reopen server socket
This appears to be a fairly generic error message and I don't have much to go by. Any ideas?
-Nathan Yeager

Adam,
I am fairly new to WL development. Are you implying that the server my client startup class is connecting to is somehow calling close on my server? I am not sure how or where this would be possible as I am connecting to the remote server on a different port.
During the 15 or so failure messages and reconnect attempts, my client can still receive messages from the remote server; I am just assuming that port 7001 just became unavailable for some reason.
Any ideas?
-Nathan
"Adam Messinger" <[email protected]> wrote:
Nathan,
It appears that client socket is calling connect() and then close(). This
makes the server's call to accept() fail because the socket is already
closed.
Regards,
Adam
"Nathan Yeager" <[email protected]> wrote in message
news:3a314bee$[email protected]..
Hi,
I am running 4.5.1 SP13. I have a startup class which registers itself asan RMI observer with a remote server. It initially connects, and receives
the first message.
Not long after receiving the first message, the following is outputnumerous times before the server shuts itself down:
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> Listen failed. Failurecount: 1
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> java.net.SocketException:socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:413)
at java.net.ServerSocket.implAccept(ServerSocket.java:241)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at weblogic.t3.srvr.ListenThread.run(ListenThread.java:280)
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> Attempting to close andreopen server socket
This appears to be a fairly generic error message and I don't have much togo by. Any ideas?
-Nathan Yeager

Similar Messages

SIGSEGV in socket accept native code (possibly RMI related)

Hi,
We've been having this problem for a while on a 1.4.2 VM (don't recall the exact version), so we upgraded to 1.5.0_03 and it got slightly worse... so we upgraded to 1.5.0_09 and it got much worse. Unfortunately, this is the latest version of the JVM that's packaged/authorised in my organisation so trying later versions isn't possible.
The problem is a Signal 11 (SIGSEGV) fault during JVM shutdown which appears to be caused by a bug in the native socket accept code. The problem seems to be exhibited by some RMI related code. This client uses RMI to talk to a server, but (as far as I know - it's using a third party closed-source library) it doesn't export any RMI objects of its own, so I'm a bit baffled why there's an RMI TCP Accept thread at all.
We've googled every conceivable combination of useful-looking terms (including Java_java_net_PlainSocketImpl_socketAccept (with and without the offset), bits of the stack trace, PC addresses, thread names, etc.) and we can turn up one or two things that look like they're related, but really nothing that appears hugely significant.
Basically, we're really stuck with this and it's a production problem so it's causing us a lot of pain. If anybody out there has the faintest clue, we'd really appreciate it.
Thanks.
====uname -a=====
(Hostname changed)
Linux host.domain.blah.com 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5 17:13:01 EST 2006 i686 athlon i386 GNU/Linux
====hs thing log file====
(NOTE: Some of the information in here has been obfuscated for commercial sensitivity, but I don't think any of it is relevant)
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGSEGV (0xb) at pc=0xb789bb79, pid=30978, tid=2638416816
# Java VM: Java HotSpot(TM) Server VM (1.5.0_09-b01 mixed mode)
# Problematic frame:
# V [libjvm.so+0x284b79]
--------------- T H R E A D ---------------
Current thread (0x08ae81a0): JavaThread "RMI TCP Accept-0" daemon [_thread_in_vm, id=14935]
siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000
Registers:
EAX=0x00000000, EBX=0xb7bcfe50, ECX=0x00000002, EDX=0x00000ffc
ESP=0x9d42ff2c, EBP=0x9d42ff64, ESI=0x08ae81a0, EDI=0x00000008
EIP=0xb789bb79, CR2=0x00000000, EFLAGS=0x00010213
Top of Stack: (sp=0x9d42ff2c)
0x9d42ff2c: 08ae81a0 08ae8260 9d42ff64 9e4e04af
0x9d42ff3c: 08ae81a0 0a5eec84 00000052 00000001
0x9d42ff4c: 00000001 9d42ffb4 9e4e02bb 9e4e5184
0x9d42ff5c: 0a5eec84 0000000b 9d42ffe4 9e4df306
0x9d42ff6c: 08ae8260 00000000 00000022 0000000b
0x9d42ff7c: 08ae81a0 afde6cb8 9d42ffc4 9d42ffac
0x9d42ff8c: 9d42ffa8 00000010 00000000 00000000
0x9d42ff9c: b7a3f669 00000000 0000c2ff 0000001c
Instructions: (pc=0xb789bb79)
0xb789bb69: 00 00 00 06 00 00 00 8b 45 0c 8b 7d 10 c1 ef 02
0xb789bb79: 8b 10 8b 83 5c 13 00 00 8b 00 8b 4a 04 85 c0 0f
Stack: [0x9d3b0000,0x9d431000), sp=0x9d42ff2c, free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x284b79]
C [libnet.so+0xb306] Java_java_net_PlainSocketImpl_socketAccept+0x276
j java.net.PlainSocketImpl.socketAccept(Ljava/net/SocketImpl;)V+0
j java.net.PlainSocketImpl.accept(Ljava/net/SocketImpl;)V+7
j java.net.ServerSocket.implAccept(Ljava/net/Socket;)V+50
j java.net.ServerSocket.accept()Ljava/net/Socket;+48
j sun.rmi.transport.tcp.TCPTransport.run()V+59
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.so+0x266eec]
V [libjvm.so+0x42da88]
V [libjvm.so+0x266745]
V [libjvm.so+0x2667de]
V [libjvm.so+0x2ddf75]
V [libjvm.so+0x4cdb13]
V [libjvm.so+0x42e698]
C [libpthread.so.0+0x5341]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.net.PlainSocketImpl.socketAccept(Ljava/net/SocketImpl;)V+0
j java.net.PlainSocketImpl.accept(Ljava/net/SocketImpl;)V+7
j java.net.ServerSocket.implAccept(Ljava/net/Socket;)V+50
j java.net.ServerSocket.accept()Ljava/net/Socket;+48
j sun.rmi.transport.tcp.TCPTransport.run()V+59
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x09274f88 JavaThread "RMI ConnectionExpiration-[10.72.14.39:40107]" daemon [_thread_blocked, id=11989]
0x08c9cc20 JavaThread "RMI ConnectionExpiration-[10.72.14.40:40107]" daemon [_thread_blocked, id=11983]
0x0903aec8 JavaThread "RMI ConnectionExpiration-[10.72.14.40:40112]" daemon [_thread_blocked, id=11982]
0x08fbc518 JavaThread "RMI ConnectionExpiration-[10.72.14.44:40113]" daemon [_thread_blocked, id=11981]
0x0813ceb8 JavaThread "RMI ConnectionExpiration-[10.72.13.183:40113]" daemon [_thread_blocked, id=11980]
0x08a6e7f0 JavaThread "RMI ConnectionExpiration-[10.72.14.40:40110]" daemon [_thread_blocked, id=11979]
0x08ee22f0 JavaThread "RMI ConnectionExpiration-[10.72.14.44:40109]" daemon [_thread_blocked, id=11978]
0x090c0ef0 JavaThread "RMI ConnectionExpiration-[10.72.14.39:40118]" daemon [_thread_blocked, id=11977]
0x091fdfb0 JavaThread "RMI ConnectionExpiration-[10.72.13.183:40109]" daemon [_thread_blocked, id=11976]
0x087dd5a0 JavaThread "RMI ConnectionExpiration-[10.72.14.39:40110]" daemon [_thread_blocked, id=10595]
0x091fe340 JavaThread "RMI RenewClean-[10.72.14.39:40110]" daemon [_thread_blocked, id=10594]
0x08e70220 JavaThread "RMI ConnectionExpiration-[10.72.14.39:53973,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=10593]
0x087de380 JavaThread "RMI RenewClean-[10.72.14.39:53973,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=10353]
0x092832e0 JavaThread "RMI RenewClean-[10.72.13.183:40109]" daemon [_thread_blocked, id=10346]
0x085c2710 JavaThread "RMI RenewClean-[10.72.13.183:40248,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=10336]
0x08a470a0 JavaThread "RMI ConnectionExpiration-[10.72.14.39:40114]" daemon [_thread_blocked, id=10327]
0x09471ca8 JavaThread "RMI RenewClean-[10.72.14.39:40114]" daemon [_thread_blocked, id=10326]
0x08e10e78 JavaThread "RMI ConnectionExpiration-[10.72.14.39:54045,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=10325]
0x08dc22b8 JavaThread "RMI ConnectionExpiration-[10.72.14.39:40112]" daemon [_thread_blocked, id=10178]
0x08dc1ae0 JavaThread "RMI RenewClean-[10.72.14.39:40112]" daemon [_thread_blocked, id=10177]
0x08dc64b8 JavaThread "RMI ConnectionExpiration-[10.72.14.39:54006,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=10176]
0x08e6ac08 JavaThread "RMI RenewClean-[10.72.14.39:54006,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=10146]
0x087d94f8 JavaThread "RMI ConnectionExpiration-[10.72.13.183:40111]" daemon [_thread_blocked, id=9948]
0x087d8df8 JavaThread "RMI RenewClean-[10.72.13.183:40111]" daemon [_thread_blocked, id=9947]
0x085c30e8 JavaThread "RMI RenewClean-[10.72.13.183:40278,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=9945]
0x085c3bb0 JavaThread "RMI ConnectionExpiration-[10.72.14.44:40111]" daemon [_thread_blocked, id=8815]
0x085c1c08 JavaThread "RMI RenewClean-[10.72.14.44:40111]" daemon [_thread_blocked, id=8432]
0x085c4940 JavaThread "RMI ConnectionExpiration-[10.72.14.44:33150,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=8241]
0x085c3f10 JavaThread "RMI RenewClean-[10.72.14.44:33150,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=8219]
0x085bee18 JavaThread "RMI ConnectionExpiration-[10.72.14.39:40116]" daemon [_thread_blocked, id=8106]
0x085be388 JavaThread "RMI RenewClean-[10.72.14.39:40116]" daemon [_thread_blocked, id=8105]
0x08e15b68 JavaThread "RMI ConnectionExpiration-[10.72.14.39:54066,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=7006]
0x085bd3b0 JavaThread "RMI RenewClean-[10.72.14.39:54066,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=6696]
0x08e152c8 JavaThread "RMI RenewClean-[10.72.14.39:40118]" daemon [_thread_blocked, id=6524]
0x08a45098 JavaThread "RMI RenewClean-[10.72.14.39:54088,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=5775]
0x09472c60 JavaThread "RMI RenewClean-[10.72.14.44:40109]" daemon [_thread_blocked, id=5771]
0x09474e00 JavaThread "RMI RenewClean-[10.72.14.44:33127,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=5769]
0x08dc1428 JavaThread "RMI RenewClean-[10.72.14.40:40110]" daemon [_thread_blocked, id=5765]
0x08dc5758 JavaThread "RMI RenewClean-[10.72.14.40:42086,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=5763]
0x092846f0 JavaThread "RMI RenewClean-[10.72.13.183:40113]" daemon [_thread_blocked, id=5759]
0x08b6cc00 JavaThread "RMI RenewClean-[10.72.13.183:40295,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=5757]
0x08b72058 JavaThread "RMI RenewClean-[10.72.14.44:40113]" daemon [_thread_blocked, id=5745]
0x08b712a0 JavaThread "RMI RenewClean-[10.72.14.44:33186,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=5726]
0x0a7339b0 JavaThread "RMI RenewClean-[10.72.14.40:40112]" daemon [_thread_blocked, id=5722]
0x08ad4d58 JavaThread "RMI RenewClean-[10.72.14.40:42110,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=5720]
0x08fbe770 JavaThread "Scheduler" daemon [_thread_blocked, id=5719]
0x0997a398 JavaThread "RMI RenewClean-[10.72.14.39:54045,com.commerciallysensitive.RMISSLClientSocketFactory@180650e]" daemon [_thread_blocked, id=15762]
0x08e1b708 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=14942]
=>0x08ae81a0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_vm, id=14935]
0x08604250 JavaThread "RMI RenewClean-[10.72.14.39:40107]" daemon [_thread_blocked, id=14931]
0x08603c78 JavaThread "GC Daemon" daemon [_thread_blocked, id=14930]
0x0911f558 JavaThread "RMI RenewClean-[10.72.14.40:40107]" daemon [_thread_blocked, id=14920]
0x08da6e20 JavaThread "Scheduler" daemon [_thread_blocked, id=14902]
0x08da7db0 JavaThread "CleanUpReference clean up thread" daemon [_thread_blocked, id=14892]
0x08121920 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=30988]
0x08120498 JavaThread "CompilerThread1" daemon [_thread_blocked, id=30987]
0x0811f438 JavaThread "CompilerThread0" daemon [_thread_blocked, id=30986]
0x0811e308 JavaThread "AdapterThread" daemon [_thread_blocked, id=30985]
0x0811d578 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=30984]
0x08110598 JavaThread "Finalizer" daemon [_thread_blocked, id=30983]
0x081100e0 JavaThread "Reference Handler" daemon [_thread_blocked, id=30982]
0x0806b288 JavaThread "main" [_thread_blocked, id=30978]
Other Threads:
0x0810dbe0 VMThread [id=30981]
0x08122dc0 WatcherThread [id=30989]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
PSYoungGen total 19008K, used 8604K [0xafa60000, 0xb1090000, 0xb1090000)
eden space 16064K, 45% used [0xafa60000,0xb01953c0,0xb0a10000)
from space 2944K, 41% used [0xb0db0000,0xb0ee1e28,0xb1090000)
to space 3328K, 0% used [0xb0a10000,0xb0a10000,0xb0d50000)
PSOldGen total 38592K, used 31818K [0xa4890000, 0xa6e40000, 0xafa60000)
object space 38592K, 82% used [0xa4890000,0xa67a2bf0,0xa6e40000)
PSPermGen total 28416K, used 20144K [0xa0890000, 0xa2450000, 0xa4890000)
object space 28416K, 70% used [0xa0890000,0xa1c3c340,0xa2450000)
Dynamic libraries:
004aa000-004bf000 r-xp 00000000 fd:00 1867896 /lib/ld-2.3.4.so
004bf000-004c0000 r-xp 00015000 fd:00 1867896 /lib/ld-2.3.4.so
004c0000-004c1000 rwxp 00016000 fd:00 1867896 /lib/ld-2.3.4.so
004c3000-005e7000 r-xp 00000000 fd:00 1867897 /lib/tls/libc-2.3.4.so
005e7000-005e8000 r-xp 00124000 fd:00 1867897 /lib/tls/libc-2.3.4.so
005e8000-005eb000 rwxp 00125000 fd:00 1867897 /lib/tls/libc-2.3.4.so
005eb000-005ed000 rwxp 005eb000 00:00 0
005ef000-005f1000 r-xp 00000000 fd:00 1868983 /lib/libdl-2.3.4.so
005f1000-005f3000 rwxp 00001000 fd:00 1868983 /lib/libdl-2.3.4.so
005f5000-00616000 r-xp 00000000 fd:00 1868961 /lib/tls/libm-2.3.4.so
00616000-00618000 rwxp 00020000 fd:00 1868961 /lib/tls/libm-2.3.4.so
006e3000-006f1000 r-xp 00000000 fd:00 1868984 /lib/tls/libpthread-2.3.4.so
006f1000-006f3000 rwxp 0000d000 fd:00 1868984 /lib/tls/libpthread-2.3.4.so
006f3000-006f5000 rwxp 006f3000 00:00 0
009dd000-009ef000 r-xp 00000000 fd:00 1869140 /lib/libnsl-2.3.4.so
009ef000-009f1000 rwxp 00011000 fd:00 1869140 /lib/libnsl-2.3.4.so
009f1000-009f3000 rwxp 009f1000 00:00 0
08048000-08057000 r-xp 00000000 fd:00 1199000 /usr/java/jdk-1.5.0_09-i386/bin/java
08057000-08059000 rwxp 0000e000 fd:00 1199000 /usr/java/jdk-1.5.0_09-i386/bin/java
08059000-0ab15000 rwxp 08059000 00:00 0
98f9f000-98fa2000 ---p 98f9f000 00:00 0
98fa2000-99020000 rwxp 98fa2000 00:00 0
99020000-99023000 ---p 99020000 00:00 0
99023000-990a1000 rwxp 99023000 00:00 0
990a1000-990a4000 ---p 990a1000 00:00 0
990a4000-99122000 rwxp 990a4000 00:00 0
99122000-99125000 ---p 99122000 00:00 0
99125000-991a3000 rwxp 99125000 00:00 0
991a3000-991a6000 rwxp 991a3000 00:00 0
991a6000-99224000 rwxp 991a6000 00:00 0
99224000-99227000 ---p 99224000 00:00 0
99227000-992a5000 rwxp 99227000 00:00 0
992a5000-992a8000 rwxp 992a5000 00:00 0
992a8000-99326000 rwxp 992a8000 00:00 0
99326000-99329000 ---p 99326000 00:00 0
99329000-993a7000 rwxp 99329000 00:00 0
993a7000-993aa000 rwxp 993a7000 00:00 0
993aa000-99428000 rwxp 993aa000 00:00 0
99428000-9942b000 ---p 99428000 00:00 0
9942b000-994a9000 rwxp 9942b000 00:00 0
994a9000-994ac000 ---p 994a9000 00:00 0
994ac000-9952a000 rwxp 994ac000 00:00 0
9952a000-9952d000 rwxp 9952a000 00:00 0
9952d000-995ab000 rwxp 9952d000 00:00 0
995ab000-995ae000 ---p 995ab000 00:00 0
995ae000-9962c000 rwxp 995ae000 00:00 0
9962c000-9962f000 ---p 9962c000 00:00 0
9962f000-996ad000 rwxp 9962f000 00:00 0
996ad000-996b0000 rwxp 996ad000 00:00 0
996b0000-9972e000 rwxp 996b0000 00:00 0
9972e000-99731000 ---p 9972e000 00:00 0
99731000-997af000 rwxp 99731000 00:00 0
997af000-997b2000 ---p 997af000 00:00 0
997b2000-99830000 rwxp 997b2000 00:00 0
99830000-99833000 ---p 99830000 00:00 0
99833000-998b1000 rwxp 99833000 00:00 0
998b1000-998b4000 ---p 998b1000 00:00 0
998b4000-99932000 rwxp 998b4000 00:00 0
99932000-99935000 ---p 99932000 00:00 0
99935000-999b3000 rwxp 99935000 00:00 0
999b3000-999b6000 ---p 999b3000 00:00 0
999b6000-99a34000 rwxp 999b6000 00:00 0
99a34000-99a37000 ---p 99a34000 00:00 0
99a37000-99ab5000 rwxp 99a37000 00:00 0
99ab5000-99ab8000 ---p 99ab5000 00:00 0
99ab8000-99b36000 rwxp 99ab8000 00:00 0
99b36000-99b39000 rwxp 99b36000 00:00 0
99b39000-99bb7000 rwxp 99b39000 00:00 0
99bb7000-99bba000 ---p 99bb7000 00:00 0
99bba000-99c38000 rwxp 99bba000 00:00 0
99c38000-99c3b000 ---p 99c38000 00:00 0
99c3b000-99cb9000 rwxp 99c3b000 00:00 0
99cb9000-99cbc000 ---p 99cb9000 00:00 0
99cbc000-99d3a000 rwxp 99cbc000 00:00 0
99d3a000-99d3d000 ---p 99d3a000 00:00 0
99d3d000-99dbb000 rwxp 99d3d000 00:00 0
99dbb000-99dbe000 rwxp 99dbb000 00:00 0
99dbe000-99e3c000 rwxp 99dbe000 00:00 0
99e3c000-99e3f000 ---p 99e3c000 00:00 0
99e3f000-99ebd000 rwxp 99e3f000 00:00 0
99ebd000-99ec0000 rwxp 99ebd000 00:00 0
99ec0000-99f3e000 rwxp 99ec0000 00:00 0
99f3e000-99f41000 ---p 99f3e000 00:00 0
99f41000-99fbf000 rwxp 99f41000 00:00 0
99fbf000-99fc2000 ---p 99fbf000 00:00 0
99fc2000-9a040000 rwxp 99fc2000 00:00 0
9a040000-9a043000 ---p 9a040000 00:00 0
9a043000-9a0c1000 rwxp 9a043000 00:00 0
9a0c1000-9a0c4000 ---p 9a0c1000 00:00 0
9a0c4000-9a142000 rwxp 9a0c4000 00:00 0
9a142000-9a145000 ---p 9a142000 00:00 0
9a145000-9a1c3000 rwxp 9a145000 00:00 0
9a1c3000-9a1c6000 ---p 9a1c3000 00:00 0
9a1c6000-9a244000 rwxp 9a1c6000 00:00 0
9a244000-9a247000 ---p 9a244000 00:00 0
9a247000-9a2c5000 rwxp 9a247000 00:00 0
9a2c5000-9a2c8000 ---p 9a2c5000 00:00 0
9a2c8000-9a346000 rwxp 9a2c8000 00:00 0
9a346000-9a349000 ---p 9a346000 00:00 0
9a349000-9a3c7000 rwxp 9a349000 00:00 0
9a3c7000-9a3ca000 ---p 9a3c7000 00:00 0
9a3ca000-9a448000 rwxp 9a3ca000 00:00 0
9a448000-9a44b000 rwxp 9a448000 00:00 0
9a44b000-9a4c9000 rwxp 9a44b000 00:00 0
9a4c9000-9a4cc000 rwxp 9a4c9000 00:00 0
9a4cc000-9a54a000 rwxp 9a4cc000 00:00 0
9a54a000-9a54d000 ---p 9a54a000 00:00 0
9a54d000-9a5cb000 rwxp 9a54d000 00:00 0
9a5cb000-9a5ce000 rwxp 9a5cb000 00:00 0
9a5ce000-9a64c000 rwxp 9a5ce000 00:00 0
9a64c000-9a64f000 ---p 9a64c000 00:00 0
9a64f000-9a6cd000 rwxp 9a64f000 00:00 0
9a6cd000-9a6d0000 rwxp 9a6cd000 00:00 0
9a6d0000-9a74e000 rwxp 9a6d0000 00:00 0
9a74e000-9a751000 ---p 9a74e000 00:00 0
9a751000-9a7cf000 rwxp 9a751000 00:00 0
9a7cf000-9a7d2000 rwxp 9a7cf000 00:00 0
9a7d2000-9a850000 rwxp 9a7d2000 00:00 0
9a850000-9a853000 ---p 9a850000 00:00 0
9a853000-9a8d1000 rwxp 9a853000 00:00 0
9a8d1000-9a8d4000 rwxp 9a8d1000 00:00 0
9a8d4000-9a952000 rwxp 9a8d4000 00:00 0
9a952000-9a955000 ---p 9a952000 00:00 0
9a955000-9a9d3000 rwxp 9a955000 00:00 0
9a9d3000-9a9d6000 rwxp 9a9d3000 00:00 0
9a9d6000-9aa54000 rwxp 9a9d6000 00:00 0
9aa54000-9aa57000 ---p 9aa54000 00:00 0
9aa57000-9aad5000 rwxp 9aa57000 00:00 0
9ae00000-9af58000 rwxp 9ae00000 00:00 0
9af58000-9b000000 ---p 9af58000 00:00 0
9b000000-9b1fa000 rwxp 9b000000 00:00 0
9b1fa000-9b200000 ---p 9b1fa000 00:00 0
9b200000-9b400000 rwxp 9b200000 00:00 0
9b400000-9b5f9000 rwxp 9b400000 00:00 0
9b5f9000-9b600000 ---p 9b5f9000 00:00 0
9b600000-9b800000 rwxp 9b600000 00:00 0
9b800000-9ba00000 rwxp 9b800000 00:00 0
9ba00000-9bb00000 rwxp 9ba00000 00:00 0
9bb7f000-9bb82000 rwxp 9bb7f000 00:00 0
9bb82000-9bcfe000 rwxp 9bb82000 00:00 0
9bcfe000-9bd00000 ---p 9bcfe000 00:00 0
9bd7d000-9bd80000 ---p 9bd7d000 00:00 0
9bd80000-9bdfe000 rwxp 9bd80000 00:00 0
9bdfe000-9be01000 rwxp 9bdfe000 00:00 0
9be01000-9be7f000 rwxp 9be01000 00:00 0
9be7f000-9be82000 ---p 9be7f000 00:00 0
9be82000-9bff2000 rwxp 9be82000 00:00 0
9bff2000-9c000000 ---p 9bff2000 00:00 0
9c02c000-9c02f000 rwxp 9c02c000 00:00 0
9c02f000-9c0ad000 rwxp 9c02f000 00:00 0
9c0ad000-9c0b0000 rwxp 9c0ad000 00:00 0
9c0b0000-9c12e000 rwxp 9c0b0000 00:00 0
9c12e000-9c131000 rwxp 9c12e000 00:00 0
9c131000-9c1af000 rwxp 9c131000 00:00 0
9c200000-9c2f8000 rwxp 9c200000 00:00 0
9c2f8000-9c300000 ---p 9c2f8000 00:00 0
9c400000-9c4ee000 rwxp 9c400000 00:00 0
9c4ee000-9c500000 ---p 9c4ee000 00:00 0
9c57f000-9c582000 rwxp 9c57f000 00:00 0
9c582000-9c6f4000 rwxp 9c582000 00:00 0
9c6f4000-9c700000 ---p 9c6f4000 00:00 0
9c77d000-9c780000 ---p 9c77d000 00:00 0
9c780000-9c7fe000 rwxp 9c780000 00:00 0
9c7fe000-9c801000 ---p 9c7fe000 00:00 0
9c801000-9c87f000 rwxp 9c801000 00:00 0
9c87f000-9c882000 rwxp 9c87f000 00:00 0
9c882000-9c9f9000 rwxp 9c882000 00:00 0
9c9f9000-9ca00000 ---p 9c9f9000 00:00 0
9ca77000-9ca7a000 rwxp 9ca77000 00:00 0
9ca7a000-9caf8000 rwxp 9ca7a000 00:00 0
9caf8000-9cafb000 rwxp 9caf8000 00:00 0
9cafb000-9cb79000 rwxp 9cafb000 00:00 0
9cb79000-9cb7c000 rwxp 9cb79000 00:00 0
9cb7c000-9cbfa000 rwxp 9cb7c000 00:00 0
9cbfa000-9cbfd000 rwxp 9cbfa000 00:00 0
9cbfd000-9cc7b000 rwxp 9cbfd000 00:00 0
9cc7b000-9cc7e000 ---p 9cc7b000 00:00 0
9cc7e000-9ccfc000 rwxp 9cc7e000 00:00 0
9cea6000-9cea9000 rwxp 9cea6000 00:00 0
9cea9000-9cf27000 rwxp 9cea9000 00:00 0
9cf27000-9cf2a000 rwxp 9cf27000 00:00 0
9cf2a000-9cfa8000 rwxp 9cf2a000 00:00 0
9cfa8000-9cfab000 ---p 9cfa8000 00:00 0
9cfab000-9d029000 rwxp 9cfab000 00:00 0
9d029000-9d02c000 ---p 9d029000 00:00 0
9d02c000-9d0aa000 rwxp 9d02c000 00:00 0
9d0aa000-9d0ad000 ---p 9d0aa000 00:00 0
9d0ad000-9d12b000 rwxp 9d0ad000 00:00 0
9d12b000-9d12e000 rwxp 9d12b000 00:00 0
9d12e000-9d1ac000 rwxp 9d12e000 00:00 0
9d1ac000-9d1af000 rwxp 9d1ac000 00:00 0
9d1af000-9d22d000 rwxp 9d1af000 00:00 0
9d22d000-9d230000 rwxp 9d22d000 00:00 0
9d230000-9d2ae000 rwxp 9d230000 00:00 0
9d2ae000-9d2b1000 rwxp 9d2ae000 00:00 0
9d2b1000-9d32f000 rwxp 9d2b1000 00:00 0
9d32f000-9d332000 rwxp 9d32f000 00:00 0
9d332000-9d3b0000 rwxp 9d332000 00:00 0
9d3b0000-9d3b3000 ---p 9d3b0000 00:00 0
9d3b3000-9d431000 rwxp 9d3b3000 00:00 0
9d431000-9d434000 rwxp 9d431000 00:00 0
9d434000-9d4b2000 rwxp 9d434000 00:00 0
9d4b2000-9d4b5000 ---p 9d4b2000 00:00 0
9d4b5000-9d533000 rwxp 9d4b5000 00:00 0
9d533000-9d536000 ---p 9d533000 00:00 0
9d536000-9d5b4000 rwxp 9d536000 00:00 0
9d5b4000-9d5b7000 ---p 9d5b4000 00:00 0
9d5b7000-9d635000 rwxp 9d5b7000 00:00 0
9d635000-9d636000 r-xp 00000000 fd:00 1214048 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/librmi.so
9d636000-9d637000 rwxp 00000000 fd:00 1214048 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/librmi.so
9d637000-9d63a000 rwxp 9d637000 00:00 0
9d63a000-9d6b8000 rwxp 9d63a000 00:00 0
9d6b8000-9d6bb000 rwxp 9d6b8000 00:00 0
9d6bb000-9d739000 rwxp 9d6bb000 00:00 0
9d739000-9d73c000 ---p 9d739000 00:00 0
9d73c000-9d7ba000 rwxp 9d73c000 00:00 0
9d7ba000-9d7bd000 ---p 9d7ba000 00:00 0
9d7bd000-9d83b000 rwxp 9d7bd000 00:00 0
9e41e000-9e421000 rwxp 9e41e000 00:00 0
9e421000-9e49f000 rwxp 9e421000 00:00 0
9e49f000-9e4d4000 r-xs 00000000 fd:00 2473232 /var/db/nscd/hosts
9e4d4000-9e4e5000 r-xp 00000000 fd:00 1214046 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libnet.so
9e4e5000-9e4e6000 rwxp 00011000 fd:00 1214046 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libnet.so
9e4e6000-9e4e9000 rwxp 9e4e6000 00:00 0
9e4e9000-9e567000 rwxp 9e4e9000 00:00 0
9e567000-9e56a000 ---p 9e567000 00:00 0
9e56a000-9e5e8000 rwxp 9e56a000 00:00 0
9f834000-9f9ef000 r-xs 00000000 fd:04 6144498 /blahblah/xerces.jar
9ffd4000-9ffd5000 ---p 9ffd4000 00:00 0
9ffd5000-a0055000 rwxp 9ffd5000 00:00 0
a0055000-a0058000 ---p a0055000 00:00 0
a0058000-a00d6000 rwxp a0058000 00:00 0
a00d6000-a00d9000 ---p a00d6000 00:00 0
a00d9000-a0157000 rwxp a00d9000 00:00 0
a0157000-a015a000 ---p a0157000 00:00 0
a015a000-a01d8000 rwxp a015a000 00:00 0
a01d8000-a01db000 ---p a01d8000 00:00 0
a01db000-a0259000 rwxp a01db000 00:00 0
a0259000-a025c000 ---p a0259000 00:00 0
a025c000-a02da000 rwxp a025c000 00:00 0
a02da000-a02db000 r-xp 00fb3000 fd:00 969958 /usr/lib/locale/locale-archive
a02db000-a030d000 r-xp 00f2c000 fd:00 969958 /usr/lib/locale/locale-archive
a030d000-a050d000 r-xp 00000000 fd:00 969958 /usr/lib/locale/locale-archive
a050d000-a0510000 ---p a050d000 00:00 0
a0510000-a058e000 rwxp a0510000 00:00 0
a058e000-a0591000 ---p a058e000 00:00 0
a0591000-a060f000 rwxp a0591000 00:00 0
a060f000-a0610000 ---p a060f000 00:00 0
a0610000-a0690000 rwxp a0610000 00:00 0
a0690000-a0691000 ---p a0690000 00:00 0
a0691000-a0711000 rwxp a0691000 00:00 0
a0711000-a0712000 ---p a0711000 00:00 0
a0712000-a07a0000 rwxp a0712000 00:00 0
a07a0000-a07b2000 rwxp a07a0000 00:00 0
a07b2000-a07c5000 rwxp a07b2000 00:00 0
a07c5000-a080b000 rwxp a07c5000 00:00 0
a080b000-a0819000 rwxp a080b000 00:00 0
a0819000-a082b000 rwxp a0819000 00:00 0
a082b000-a083e000 rwxp a082b000 00:00 0
a083e000-a0883000 rwxp a083e000 00:00 0
a0883000-a088f000 rwxp a0883000 00:00 0
a088f000-a2450000 rwxp a088f000 00:00 0
a2450000-a4890000 rwxp a2450000 00:00 0
a4890000-a6e40000 rwxp a4890000 00:00 0
a6e40000-afa60000 rwxp a6e40000 00:00 0
afa60000-b1090000 rwxp afa60000 00:00 0
b1093000-b10a6000 rwxp b1093000 00:00 0
b10a6000-b1153000 rwxp b10a6000 00:00 0
b1153000-b15e3000 rwxp b1153000 00:00 0
b15e3000-b4153000 rwxp b15e3000 00:00 0
b4153000-b49c3000 r-xs 00000000 fd:00 1200731 /usr/java/jdk-1.5.0_09-i386/jre/lib/charsets.jar
b49c3000-b49d8000 r-xs 00000000 fd:00 1200759 /usr/java/jdk-1.5.0_09-i386/jre/lib/jce.jar
b49d8000-b4a5d000 r-xs 00000000 fd:00 1200760 /usr/java/jdk-1.5.0_09-i386/jre/lib/jsse.jar
b4a5d000-b4ac6000 rwxp b4a5d000 00:00 0
b4ac6000-b70dc000 r-xs 00000000 fd:00 1200767 /usr/java/jdk-1.5.0_09-i386/jre/lib/rt.jar
b70dc000-b70eb000 r-xp 00000000 fd:00 1214052 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libzip.so
b70eb000-b70ed000 rwxp 0000e000 fd:00 1214052 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libzip.so
b70ed000-b710e000 r-xp 00000000 fd:00 1214032 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libjava.so
b710e000-b7110000 rwxp 00020000 fd:00 1214032 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libjava.so
b7110000-b711b000 r-xp 00000000 fd:00 1214051 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libverify.so
b711b000-b711c000 rwxp 0000b000 fd:00 1214051 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/libverify.so
b711c000-b7124000 rwxs 00000000 fd:00 2392802 /tmp/hsperfdata_elm_d/30978
b7124000-b760e000 r-xs 00000000 fd:00 2473112 /var/db/nscd/passwd
b760e000-b7614000 r-xp 00000000 fd:00 1214056 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/native_threads/libhpi.so
b7614000-b7615000 rwxp 00006000 fd:00 1214056 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/native_threads/libhpi.so
b7615000-b7616000 rwxp b7615000 00:00 0
b7616000-b7617000 r-xp b7616000 00:00 0
b7617000-b7b71000 r-xp 00000000 fd:00 1214060 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/server/libjvm.so
b7b71000-b7bd4000 rwxp 0055a000 fd:00 1214060 /usr/java/jdk-1.5.0_09-i386/jre/lib/i386/server/libjvm.so
b7bd4000-b7fed000 rwxp b7bd4000 00:00 0
bfe00000-bfe03000 ---p bfe00000 00:00 0
bfe03000-c0000000 rwxp bfe03000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
VM Arguments:
jvm_args: -Xmx200M -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy -Djava.security.manager -Djava.security.policy=/blah/blah/blah.policy -Dsun.rmi.dgc.client.gcInterval=72000000 -Dsun.rmi.dgc.server.gcInterval=72000000
java_command: blahblahblah
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/usr/java/jdk-1.5.0_09-i386
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
LD_LIBRARY_PATH=/usr/java/jdk-1.5.0_09-i386/jre/lib/i386/server:/usr/java/jdk-1.5.0_09-i386/jre/lib/i386:/usr/java/jdk-1.5.0_09-i386/jre/../lib/i386
Signal Handlers:
SIGSEGV: [libjvm.so+0x508860], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGBUS: [libjvm.so+0x508860], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGFPE: [libjvm.so+0x42cac0], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGPIPE: [libjvm.so+0x42cac0], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGILL: [libjvm.so+0x42cac0], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x42ef10], sa_mask[0]=0x00000000, sa_flags=0x14000004
SIGHUP: [libjvm.so+0x42e940], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGINT: [libjvm.so+0x42e940], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGQUIT: [libjvm.so+0x42e940], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
SIGTERM: [libjvm.so+0x42e940], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
uname:Linux 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5 17:13:01 EST 2006 i686
libc:glibc 2.3.4 NPTL 2.3.4
rlimit: STACK 10240k, CORE 0k, NPROC 131071, NOFILE 1024, AS infinity
load average:30.16 19.62 12.95
CPU:total 2 (cores per cpu 1, threads per core 1) family 15 model 37 stepping 1, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnowext, 3dnow
Memory: 4k page, physical 8145028k(148604k free), swap 1023k(997k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_09-b01) for linux-x86, built on Sep 7 2006 13:17:49 by java_re with gcc 3.2.1-7a (J2SE release)

There's no JNI component of RMI so this is only an RMI problem to the extent that RMI uses TCP. It's a Java TCP accept() problem.That's what I figured. Shame nobody else on the entire Internet appears to have experienced the same problem... :-( Nevertheless, there is no native code in our application so it's looking like a bug in the native socket accept implementation, yes? And that appears to be exacerbated by RMI and/or our use of RMI.
I suspect we are (or the third party code is) doing something strange at VM shutdown since the crash always happens after a log output saying that the process has completed its work. So my current lines of attack are around JVM shutdown handlers, finalizers, etc.
Our project also uses OpenAdaptor (open source ETL tool) and I discovered that this by default calls runFinalizersOnExit(true), so we're going to try re-configuring that today too in case there's something dodgy going on with the finalizers somewhere.
That EDI register of 0x8 looks very suspicious. Have you tried the Bug Parade?Your expertise extends to understand the underlying hardware implemention? Is there no end to your talents ejp?! :-)
I have tried the bug parade but there's nothing obvious there. Plus, it's just about the worst bug tracking system in existance (to go with the worst forum software I guess! LOL) and things just get closed with no comment, or ignored, or turn into a flame war, etc... Still, I tried and didn't have any luck.
Thanks ejp!

Socket.accept() method ?

Hi,
I'm trying to write a networking app. The client seems to work - it sends a String object through an ObjectOutuptStream.
The problem seems to be that the socket.accept() method in the server isnt working!
//PlusServer.java
//Server that takes commands from Android Client, executes commands & finally returns result.
import java.net.*;
import java.io.*;
public class PlusServer
    //instance variables
    static Boolean finished = false;
    //Main method
    public static void main(String[] args)
        System.out.println(" 000 Entered Main method");
        //Disable Security Manager
        //System.setSecurityManager(null);
            try
        ServerSocket listener = new ServerSocket(1234);
        System.out.println("0 setup ServerSocket on port 1234");
            while(!finished)
                Socket client = listener.accept();//wait for connection
                //The program doesn't proceed any further! Why?
                InputStream in = client.getInputStream();
                OutputStream out = client.getOutputStream();
                //read cmd
                ObjectInputStream oin = new ObjectInputStream(in);
                String cmd = (String)oin.readObject();
                if (cmd.equals("Connect"))
                    client.close();
                    finished=true;
                //Send results
                // blah, blah, blah
            listener.close();
            catch(Exception e){System.out.println("Error: "+e);}
}The code for the client is available in another forum, here:
http://androidforums.com/developer-101/144926-android-network-programming.html#post1333747

If you plan to use ServerSocket for networking in java, you better get much more familiar and friendly with threads, cause you are going to need them.
I can't look at the other forum from work to see what the client code is, but your code looks really funny here.
Some advice, you are obviously new to this part of java coding, stick to sending strings instead of objects while you are new, it is much easier if you just stick to sending strings, and there is nothing you can't do by just sending strings. Even though in some cases sending objects is the better approach, first learn how to do client server communications the easy way and it will then naturally come to you when you should use objects. Your program clearly could have used strings only. And I am willing to bet that you would have possibly seen the problem yourself if you had.
Also, this is a very poor algorithm. What happens if you want to send two objects (or two strings if you adhear to my advice above)? Do you really think it is necessary and sound to have to reconnect the server and client for every objoct/string you want to send between them? In some cases, perhaps not this one since you are communicating with a mobile device it seems, it is ideal to not ever terminate the connection between the client and server, but instead allow threads to handle keeping open lines of communication.
Now, were I a betting man, I would bet that in your client code you are either neglecting to flush at all, or doing it incorrectly. Again I can't see that code so I am not certain, but that is a common mistake for people new to this and its symptoms fit with what you are describing seeing perfectly. I highely recomend using autoflush, especially to someone new to network programming.
JSG
Edited by: JustSomeGuy on Aug 10, 2010 11:29 AM
Edited by: JustSomeGuy on Aug 10, 2010 11:30 AM

Failure upon Socket.accept

We are seeing our logs filling with the following exception:
Wed Sep 20 20:23:14 PDT 2000:<E> <ListenThread> Listen failed, failure
count: '1'
java.net.SocketException: Software caused connection abort
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.socketAccept(Compiled Code)
at java.net.PlainSocketImpl.accept(Compiled Code)
at java.net.ServerSocket.implAccept(Compiled Code)
at java.net.ServerSocket.accept(Compiled Code)
at weblogic.t3.srvr.ListenThread.run(Compiled Code)
Has anyone else experienced this?
We are running WLS 5.1, Solaris 7, and Solaris_JDK_1.2.1_04. The soft
limit for file descriptors is 1024, the hard limit is 4096. We are no
where near the file descriptor limit.
Thanks
Kevin

Adam,
I am fairly new to WL development. Are you implying that the server my client startup class is connecting to is somehow calling close on my server? I am not sure how or where this would be possible as I am connecting to the remote server on a different port.
During the 15 or so failure messages and reconnect attempts, my client can still receive messages from the remote server; I am just assuming that port 7001 just became unavailable for some reason.
Any ideas?
-Nathan
"Adam Messinger" <[email protected]> wrote:
Nathan,
It appears that client socket is calling connect() and then close(). This
makes the server's call to accept() fail because the socket is already
closed.
Regards,
Adam
"Nathan Yeager" <[email protected]> wrote in message
news:3a314bee$[email protected]..
Hi,
I am running 4.5.1 SP13. I have a startup class which registers itself asan RMI observer with a remote server. It initially connects, and receives
the first message.
Not long after receiving the first message, the following is outputnumerous times before the server shuts itself down:
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> Listen failed. Failurecount: 1
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> java.net.SocketException:socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:413)
at java.net.ServerSocket.implAccept(ServerSocket.java:241)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at weblogic.t3.srvr.ListenThread.run(ListenThread.java:280)
Fri Dec 08 14:53:39 CST 2000:<E> <ListenThread> Attempting to close andreopen server socket
This appears to be a fairly generic error message and I don't have much togo by. Any ideas?
-Nathan Yeager

Socket communication failure between Java applet and C++ application

I have a java applet that connects to a C++ application via Java's ServerSocket and Socket objects. THe C++ application is using the Winsock 2 API. The applet and application are running on an NT workstation (SP 6) and using IE (5.5) For a very simple C++ test applications the communictions work fine. Once more code gets added to the C++ application the portion of the socket that C++ listens to seems to close. Upon performing a recv call the return value is a zero. Microsoft insists this is a sign the Java side has shut down the socket. The Java applet can still receive messages from the C++ app but C++ cannot receive responses from the Java side. Java throws no exceptions and an explicit check of the socket shows no errors. Again, what puzzles me is that it works for simple C++ applications. Are there any known conflicts between Java and C++ in this regard?
I have inlcuded the basic java code segments below.
/ run Method.
* This method is called by the Thread.start() method. This
* method is required for the implementation of the Runnable interface
* This method sets up the server side socket communication and
* contiuously loops looking for requests from a external
* socket.
* @author Chris Duke
public void run(){
     // create socket connections
     boolean success = false;
     try {
         cServerSocket = new ServerSocket(cPortID);
         System.out.println("Waiting for client to connect...");
         cClientSocket = cServerSocket.accept();
         System.out.println("Client connected");
         // Create a stream to read from the client
         cInStream = new BufferedReader(new InputStreamReader(
           cClientSocket.getInputStream()));
         // Create a stream to write to the client
         cOutStream = new PrintWriter(
           cClientSocket.getOutputStream(), true);
         success = true;
     }catch (IOException e) {
         System.out.println("CommSocket:Run - Socket Exception(1) " + e);
         success = false;
     // if the socket was successfully created, keep the thread running
     while (success){
         try{
            // check socket to see if it is still available for reading
            if (cInStream != null && cInStream.ready()){
                // check for an incoming message
                String message = ReceiveMessage();
                // Send message to listeners
                Event(message);
            if (cInStream == null){
                success = false;
                System.out.println("CommSocket:Run - shutdown");
         }catch (IOException e){
            System.out.println("CommSocket:Run - Socket not ready exception");
            break;
// SendMessage method -
* Sends a text message to a connected listener through port specified by portID
* @author Chris Duke
* @param String message - This will be the message sent out through the server
* socket's port specified by portID.
   public void SendMessage(String message){
      cOutStream.println(message);
      if (cOutStream.checkError() == true)
        System.out.println("SendMessage : Flush = Error");
      else{
        System.out.println("SendMessage : Flush - No Error");
   }

a very simple C++ test applications the communictions work fine. Once more code gets added to the C++ application the portion of the socket that C++ listens to seems to close.
This quite strongly implicates the extra code in the C++ App. The firstly thing I would try would be telnet. Try connecting to both versions of the C++ Application and manually reproducing a proper exchange.
a recv call the return value is a zero. Microsoft insists this is a sign the Java side has shut down the socket.
A correct implementation of recv should return the number of bytes received, or -1 for an error. A zero return indicates no bytes received not a socket closed/error. This sounds like FUD to me.
Are there any known conflicts between Java and C++ in this regard?
I can see no obvious faults, though the code is incomplete, I don't think it's an sockets implementation issue, at either end, it sounds more likely to be a protocol/handshaking bug in the C++ App.

SIGPIPE and socket accept() calls

Hi!
I am developing a client/server application that utilises TCP stream sockets for communication between multiple clients and a single server. The main server thread creates a socket, binds it, listens and waits to accept incoming socket connections. When a connection is established it farms of a thread to handle the client's request. The server is being developed on SunOS 5.8 (sparc).
My problem is that the server receives a SIGPIPE during a blocking call to accept() shortly after a one (and only one) client initiates a connection.
I can't find any suporting documentation as to why SIGPIPE would be raised during an accept() call.
I mean, accept() accepts the socket and returns a file descriptor to the socket. If the client teared down the connection (which the client ISN'T doing) after connecting then I would expect the server to have a valid socket descriptor and EPIPE or SIGPIPEs to occur whenever the server calls socket operations like send() or recv().
Any ideas why the SIGPIPE might be happening in accept()?

Get a new iPhone. it's very difficult to get all the water out of the phone and corrosion will occur inside. Your phone will likely not be reliable even if it recovers.

VISA 3.2 SOCKET connection failure

There is a failure in VISA 3.2. It is impossible to read data trough RAW SOCKET type connection (for example) TCPIP::w15uxe4440A.ifw-dresden.de::5025:OCKET if data length is more that 4 M bits. I am sending NI Spy log to you. Look at line #81. Requested data is 4000008 bits, output buffer cnt 3998595. It should be noted that reading works fine if Agilent library is used. I have got two computer one with NI VISA, the second with Agilent VISA.
Sincerely,
Mikhail Kozlov
Attachments:
Capture SOCKET.zip ‏91 KB

Thank you Josh for your asststance.
Unfortunately I cannot find VI_ATTR_SUPPRESS_END_EN attribute
When I view all Settable Attributes in NI MAX I have got the following:
For SOCKET type connection
TCPIP::w15uxe4440A::5025:OCKET
User Data = 0x00000000
Maximum Queue Length = 50
Send End on Writes = VI_TRUE
Timeout Value = 2000
Termination Character = 0x0A
Termination Char Enable = VI_FALSE
IO Protocol = 1
Allow DMA Transfers = VI_FALSE
File Append Enable = VI_FALSE
TCP/IP No Packet Delay = VI_TRUE
TCP/IP Keep-Alive Packets = VI_FALSE
For VXI 11.3 connection
TCPIP::w15uxe4440A::inst0::INSTR
User Data = 0x00000000
Maximum Queue Length = 50
Send End on Writes = VI_TRUE
Timeout Value = 2000
Termination Character = 0x0A
Termination Char Enable = VI_FALSE
Allow DMA Transfers = VI_FALSE
File Append Enable = VI_FALSE
TCP/IP Keep-Alive Packets = VI_FALSE
It should be noted that if I change record length and requested data is 8000008 bits, output buffer cnt is 7998595.
Mikhail Kozlov

How to determine reason for socket write failure

Hi,
I'm new to socket programming in general, so please bear with me. I've looked around on the forums quite a bit, and haven't found an answer to this question.
I'm working with server code which creates TCP connections over an air interface with a mobile phone client. Since the air interface is inherently unstable, we rely on the TCP buffering/retry mechanism to store up to its capacity of messages if the client is temporarily non-responsive. Since we are sending small amounts of data, this will actually last for quite a while (several minutes or more depending on how much data we are needing to send). As part of an audit mechanism to detect lost clients, I do a write of a "heartbeat" to the socket and if the write fails, I can assume that either the buffer is full (meaning the mobile "went away" either due to loss of battery power, driving through a very long tunnel, etc.), or the mobile actively disconnected the socket.
However, I'd like to know if there is a way to determine the reason for the write failure? I catch the exception, but as far as I can tell they are all IOExceptions. Is there any way to further delineate the reason for a socket failure?
Any help would be greatly appreciated.
Thanks,
-Lisa

If you're in a hurry, I don't have an answer for you.
That said, it was an intriguing enough question that I did some poking around as well. There is a socket exception class, but generally speaking, the only methods that throw socket exceptions tend to deal with defining, creating and closing the socket.
Communicating through the socket is done through input and output streams, and like any other streams, those throw I/O exceptions. I suspect you're catching IOEs because you're using streams. Unfortunately, even Socket.sendUrgentData( int data ) also returns an IOException rather than an SException.
In the interests of covering all the bases, are the IOE messages unsufficient? That is, try...
   } catch ( IOException ioe ) {
      System.out.println( "IOException: " + ioe.getMessage() );
   }...might give you enough information to make a guess at whether the buffer is full or if the foreign host has closed the connection. I would suspect this feature is architecture dependent - UNIX systems might have more detail than Wintel systems.
As a last resort, you could extend the InputStream class and do the appropriate testing when writing/sending your packet. I would think that the only cases you can test for are whether the buffer is full (by maintaining a copy of the buffer and updating as appropriate), the mobile is currently sending data, or if the mobile is just not available.
Conventional Java isn't really the best for this because I'm not sure the JVM security model really wants to allow you to directly analyze TCP packets (otherwise you could just check for ACK statements). JME might have an easy solution that we didn't know about and you should ask on the appropriate forum. Alternatively, you might want to think about using C to write a library that handles connections this way, and externally call the library from the rest of your Java program.

Socket Accept.

Hi,
Due to certain reasons I'm still using jdk118 ... on RedHat 7.2 with kernel 2.4.7-10
The problem is, I've a code which looks like:
while(threadRunning)
try
NewSocket = s.accept();
catch(IOException e)
Debug.print("ERROR 1");
catch(Exception e)
Debug.print("ERROR 2");
When accept is encountered for the first time, it runs as expected. But next time onwards it start printing "ERROR 1", it seems it is not blocking.
On RedHat 7.0/6.2 it is working fine but it gives this behavior on 7.2.
Otherwise the program is working fine, but I wonder why this message keeps popping up.
Anyhelp in this direction is appreciated.
Thanks
MS

how strong are these "reasons" to use jdk1.1.8? Instead of printing out "ERROR 1", print something out more usefull. Trying e.getMessage() or print out a stack trace.

Ports used by the child socket which was created by server_socket.accept()?

When a server socket creates a child socket, on which port it(child) listens? When I tried to print getLocalPort(), it is always printing the port on which server was listening. When a server socket accepts a connection it creates a new socket, I think. It should listen on a port other than the server socket's port. Otherwise if all the child sockets and server listen at the same port my Multithreaded server should not work. Fortunately it is working.
Can anyone of you please clarify this child-port-number?
Seems that Sun people limited the length of the subject field. Is it?
Seenu.

when you create the socket on your clients you can specify which port the client will communicate from, otherwise it will be randomly generated by the machine:
// CONSTRUCTOR TO USE
Socket(InetAddress address, int port, InetAddress localAddr, int localPort)
just to clear something up, why do you care what the client ports are unless you are CLOSING the connection first, re-opening, and sending data back. once the client connects the stream is open. the only port you need to free up for your firewall is the port the sever socket is listening on so the clients dont get rejected when trying to connect.
i hope this helps.
~ranemaker

Adding Accepted Socket to Selector

OK,
I have gleaned the java.nio.channels.Selector et al.
I think I understand how to accept a socket. However, once I have; how do I add it to the Selector so that I can register for events on the new connected socket. Here is my source:
Set<SelectionKey> fdset = null;
Socket sock = null;
ServerSocket lstn = null;
selInst = Selector.open();
do
if( null==lstn )
ServerSocketChannel rChan = selInst.provider().openServerSocketChannel();
lstn = rChan.socket();
lstn.bind( new InetSocketAddress(2007) );
rChan.register( selInst, SelectionKey.OP_ACCEPT );
if( 0>selInst.select() )
continue;
fdset = selInst.selectedKeys();
for( SelectionKey key : fdset )
if( key.isAcceptable() )
ServerSocketChannel rCh0 = (ServerSocketChannel)key.channel();
sock = rCh0.socket().accept();
rCh0.register( selInst, SelectionKey.OP_READ )
//xx wait a minute -- ServerSocketChannel::socket() returns a ServerSocket,
//xx not a Socket class, don't I need a new SocketChannel? How do I
//xx attach my accepted socket?
} while( true );
See the comments above. The jist is there is no way to open() a new SocketChannel using an existing Socket class [returned by accept()], as far as I can tell.
Thanks,
James
Beverly, MA

I posted it as an official bug. Here is the tiny app I wrote to reproduce the problem:
* James A. Renton
* Beverly, MA
public class Main
    public Main()
    static void DoOtherWork( )
    {   //xx THIS function symbolizes other stuff
        //xx my thread could do as a result of using NIO
        //xx SUCH AS read and handle internal
        //xx process-specific message queue for
        //xx starting/stopping this thread
        //xx initiating work to be delegated
        //xx to the far end machine this thread communicates with.
        try{ Thread.sleep( 1000 );}catch( Throwable rEx ){/*NOOP*/};
    static ServerSocketChannel listen( Selector rSel, String zItfIP, int nPort )
        try
            ServerSocket sockLstn = null;
            ServerSocketChannel chanLstn = rSel.provider().openServerSocketChannel();
            chanLstn.configureBlocking(false);
            sockLstn = chanLstn.socket();
            sockLstn.bind( new InetSocketAddress(zItfIP,nPort) );
            chanLstn.register( rSel, SelectionKey.OP_ACCEPT );
            return chanLstn;
        catch( java.io.IOException rEx )
            System.out.printf( "accept SETUP FAILED, ERR=[%s]\n", rEx.toString() );
            return null;
    static SocketChannel connect( Selector rSel, String zTargetIP, int nPort )
        try
            SocketChannel chanOut = rSel.provider().openSocketChannel();
            chanOut.configureBlocking(false);
            if( chanOut.connect(new InetSocketAddress(zTargetIP,nPort)) )
                chanOut.register( rSel, SelectionKey.OP_READ );
            else
                chanOut.register( rSel, SelectionKey.OP_CONNECT );
            return chanOut;
        catch( java.io.IOException rEx )
            System.out.printf( "connect SETUP FAILED, ERR=[%s]\n", rEx.toString() );
            return null;
    static Selector GetSel( )
        try { return Selector.open(); }
        catch( java.io.IOException rEx )
            System.out.printf( "Selector.open() FAILED, ERR=[%s]\n", rEx.toString() );
            return null;
    static int DoSelect( Selector rSel, int millis )
        try { return rSel.select( millis ); }
        catch( java.io.IOException rEx )
            System.out.printf( "select() FAILED, ERR=[%s]\n", rEx.toString() );
            return -1;
    public static void main(String[] args)
        int nConnected = 0;
        java.util.Set<SelectionKey> fdset = null;
        System.out.printf( "java.version=[%s]\n", System.getProperty("java.version") );
        System.out.printf( "os.name=[%s]\n", System.getProperty("os.name") );
        System.out.printf( "os.version=[%s]\n", System.getProperty("os.version") );
        Selector selInst = GetSel();
        listen( selInst, "localhost", 2008 );
        connect( selInst, "localhost", 2008 );
        while( 0<=DoSelect(selInst,150) )
            fdset = selInst.selectedKeys();
            if( !fdset.isEmpty() )
                for( SelectionKey key : fdset )
                    try
                        if( key.isAcceptable() )
                            ServerSocketChannel chanLstn = (ServerSocketChannel)key.channel();
                            SocketChannel chanAccept = chanLstn.accept();
                            if( null==chanAccept )
                                System.out.println( "*** BUG0 : KEY FLAGGED ACCEPTING, NOTHING TO ACCEPT!" );
                            else
                                InetSocketAddress addr[] = new InetSocketAddress[2];
                                chanAccept.configureBlocking(false);
                                chanAccept.register( selInst, SelectionKey.OP_READ );
                                addr[0] = (InetSocketAddress)chanAccept.socket().getLocalSocketAddress();
                                addr[1] = (InetSocketAddress)chanAccept.socket().getRemoteSocketAddress();
                                System.out.printf( "ACCEPTED SOCK (%s)<-(%s) OK.\n",
                                                    addr[0].toString(), addr[1].toString() );
                        else if( key.isConnectable() )
                            SocketChannel rCh = (SocketChannel)key.channel();
                            Boolean bRC = rCh.finishConnect();
                            key.interestOps(SelectionKey.OP_READ);
                            if( 0!=nConnected++ )
                                System.out.printf( "*** BUG1 : KEY FLAGGED CONNECTING, ALREADY CONNECTED, RC=[%s]\n",
                                                    bRC.toString() );
                            else
                                InetSocketAddress addr[] = new InetSocketAddress[2];
                                addr[0] = (InetSocketAddress)rCh.socket().getLocalSocketAddress();
                                addr[1] = (InetSocketAddress)rCh.socket().getRemoteSocketAddress();
                                System.out.printf( "CONNECT SOCK (%s)->(%s) OK, RC=[%s]\n",
                                                    addr[0].toString(), addr[1].toString(), bRC.toString() );
                    catch( java.io.IOException rEx )
                        System.out.printf( "UnHandled IOException, ERR=[%s]", rEx.toString() );
                        rEx.printStackTrace();
            DoOtherWork();
}

Systemd socket launching service and failing

I'm creating an AUR package for poppassd (POP3 Password Changing Service). The application runs in command line using stdin/stdout but is intended to be run using xinetd and pipe the socket as I/O. The code works fine when I run via command line
$ sudo /usr/bin/poppassd
200 poppassd
QUIT
500 Username required
$
When I start the socket
systemctl start poppassd.socket
the socket opens and when I try to use telnet to connect I get a disconnect right away and journalctl reports the service exited with a status of 1/FAILURE
Any ideas why the following service and socket files are not working?
poppassd.service
[Unit]
Description=POP3 Password Change Service
[Service]
ExecStart=/usr/bin/poppassd
StandardInput=socket
StandardOutput=inherit
StandardError=journal
poppassd.socket
[Socket]
ListenStream=0.0.0.0:106
[Install]
WantedBy=sockets.target

Note: i've never used poppassd and have not tested what i am about to suggest.
Since poppassd is written to be invoked by inetd with the nowait flag, it probably wants to be started with an accepted socket, not a listening socket. To do this in systemd, first add the following to the [Socket] section of poppassd.socket:
Accept=true
Then change the name of poppassd.service to [email protected]
Some socket activated template services (ie. [email protected]) also prepend '-' to the ExecStart value to prevent a single failed instance from throwing the service into a failed state.

How should i protect accept() method from TooManyOpenFiles?

I am calling accept() method assuming it will always work, considering it might result in NULL, but i've noticed in some situations the accept will fail and result in a CPU problem because it fails and since i did not do anything with the failure the key might still be valid and it tries to accept over and over again.
What is the right thing to do here - should i surround with try-catch and it will not attempt to accept the connection again?
        SocketChannel channel = ((ServerSocketChannel) key.channel()).accept();
        if (channel != null)
            if (!isApprovedClient(channel))
                channel.close();
                channel = null;
                rejectedClients++;
                return;
            acceptedClients++;
            channel.configureBlocking(false);
            BasicContext context = onClientAccept(channel);
            context.setCurrentSocket(channel);
            context.setEstablishTime();
            channel.register(selector, SelectionKey.OP_READ, context);
            log.log(Level.FINER, "Added main-channel {0}", channel.socket().getInetAddress());
        }

I am calling accept() method assuming it will always work, considering it might result in NULL, but i've noticed in some situations the accept will failFail how?
and result in a CPU problemWhat CPU problem?
because it fails and since i did not do anything with the failure the key might still be validWhat key? The key of the ServerSocketChannel? It is valid until you close or deregister it. Nothing to do with accept failures.
and it tries to accept over and over again.If the accept fails there is no SocketChannel to leak/to be closed.

Not able to read data in accept of SSLServerSocket

I have created a RMIServerSocketFactory and creating a SSLServerSocket.The code is mentioed below. The ABCServerSocket is an extended class of SSLServerSocket.The accept call is overriden in ABCServerSocket.
The ABCServerSocket will be listening on two ports . One is the request from RMISSLClient requestes as well as normal SSLClient requests.
At the client side I was just sending an integer and expecting to read the data in the accept call. But, I couldn't succeeded to read the data.
Everytime it returns me a junk value or sometimes the call was blocking. Please let me know how could I recieve the data from the client side.
Any inputs?
public class ServerSocketFactory implements RMIServerSocketFactory,Serializable
public ServerSocket createServerSocket(int port) throws IOException
try
SSLServerSocket sslSocket=new ABCServerSocket(port);
catch(Exception e){
e.printStackTrace();
public class ABCServerSocket extends SSLServerSocket
SSLSocketFactory defaultSSF;
SSLServerSocket serversocket;
public ABCServerSocket(int port) throws IOException
defaultSSF =(SSLSocketFactory)SSLSocketFactory.getDefault();
SSLServerSocketFactory sslSSF = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
serversocket=(SSLServerSocket)sslSSF.createServerSocket(port);
serversocket.setNeedClientAuth(true);
public Socket accept() throws IOException
SSLSocket sslsocket=null;
sslsocket=(SSLSocket)serversocket.accept();
InputStream in=sslsocket.getInputStream();
BufferedInputStream bin=new BufferedInputStream(in);
bin.mark(8);
DataInputStream din=new DataInputStream(bin);
try
{//The Blocking call
int data=din.readInt();
catch(Exception e){
e.printStackTrace();
}

Why are you doing all this?
Why is the ABCServerSocket listening on two ports?
When and how do you accept from the other port?
How and when is the client sending the integer?

Need help w/ wierd problem maybe caused by RMI/sockets

Hi.
I'm having a potential problem at a customer site which
has me completely baffled and with which I could do with
some help.
I've written and deployed at the customer site an Client/
Server application, developed using RMI. The problem occurs
on the server side.
I've implemented my own SocketFactory and am restricting
the sockets to ports 8091 and 8091 - through the SocketFactory
and through the constructor of java.rmi.server.UnicastRemoteObject.
The server is waiting for incoming commections. The DGC
regularly does maintenance and garbage collection, triggering
my SocketFactory. Server machine is Windows 2000. The server
machine has local server ports 8090 and 8091 in LISTENING
state (on 0.0.0.0:8090 and 0.0.0.0:8091).
The server, machine A, is waiting for incoming connections from
the client application, on machine B, which is not running. On the
same network segment are machines C, D and E (all Linux machines),
on which NONE of my software is running, and which should have
NOTHING to do with my system. These machines are communicating
amongst themselves, but not with machine A.
The customer claims (I'm not on-site, so I can't check), that
after a random time of running my server application 24/7 (the
first time after about a week, the second time after only 3 hours),
machines C, D and E were no longer able to exchange data. As soon
as my server application on machine A is aborted, systems C,
D and E are again able to exchange data - immediately.
What I don't understand is:
How is it possible, that an RMI server application, which
has opened sockets, accept()s them, has the open sockets
in LISTENING state, but is not actively sending data,
IN ANY WAY influences the traffic on the rest of the subnet?
Do opened Sockets in the accept() state send ANY form of
traffic over the network?
Is there any way I can influence other machines on the
network, simply by opening a bunch of inbound sockets? To
the best of my understanding of networks and TCP/IP there
should be no way to do that. Or am I wrong?
Again, I'd appreciate any help or pointer or even wild
theory related to this problem.
Thanks,
Daniel

For starters, why don't you try changing the ports you are using?

Socket Accept failure

Similar Messages

Maybe you are looking for