Prev: Spam on Usenet groups
Next: Anybody using their Java IDE with the C++ plugin?
From: FutureScalper on 30 Apr 2010 11:07

I have a situation where a number of local Java processes register
themselves in a local rmiregistry so they can talk to each other. All
the correct things are being done, and this works 99.9% of the time
perfectly. Each process uses a unique name "XXServer" to bind, etc.

Each process periodically unbinds and rebinds itself to the registry
successfully. But when this Connection refused problem occurs
(rarely), even though a process unbinds and rebinds itself
successfully in the registry, it cannot nvoke RMI methods, due to
connection refused.

url is correct, specifying port, etc, there is no issue in this area.
No firewalls.

This Connection refused runtime problem in the problem process never
resolves itself, and I don't know what I can do to get the process to
recover from this error. All other processes continue to work
normally, until they might rarely experience the same issue.

When I kill and restart the particular application process , then
everything is again normal. So it's that particular process which is
somehow being refused connection due to < insert solution here > I
can't reproduce the problem easily, but once it happens the process
never recovers.

sun.rmi.transport.tcp.TCPEndpoint.newSocket is where the Connection
refused originates. I wonder how I can avoid what appears to be some
resource limitation problem near TCPEndpoint as in the stack trace
below (no line numbers). I'm trying to invoke an RMI method at the
time of exception.

Java 6 Update 17

java.rmi.ConnectException: Connection
refused to host: 127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused: connect
java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
nested exception is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown
Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown
Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at
com.twc.remote.RemoteIndicatorServiceImpl_Stub.getAskRunLengthFast(Unknown
<------- invoking
Source)
at com.twc.trader.TradeEntryManager$AutoTrader.run(Unknown
Source)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown
Source)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown
Source)
... 6 more
From: FutureScalper on 30 Apr 2010 11:16

Perhaps I need to do this:

sun.rmi.transport.tcp.TCPEndpoint

public static void shedConnectionCaches()

Release idle outbound connections to reduce demand on I/O resources.
All transports are asked to release excess connections.

Seems to me something is accumulating in this area.

On Apr 30, 11:07 am, FutureScalper <futurescal...(a)gmail.com> wrote:
> I have a situation where a number of local Java processes register
> themselves in a local rmiregistry so they can talk to each other.  All
> the correct things are being done, and this works 99.9% of the time
> perfectly.  Each process uses a unique name "XXServer" to bind, etc.
>
> Each process periodically unbinds and rebinds itself to the registry
> successfully.  But when this Connection refused problem occurs
> (rarely), even though a process unbinds and rebinds itself
> successfully in the registry, it cannot nvoke RMI methods, due to
> connection refused.
>
> url is correct, specifying port, etc, there is no issue in this area.
> No firewalls.
>
> This Connection refused runtime problem in the problem process never
> resolves itself, and I don't know what I can do to get the process to
> recover from this error.   All other processes continue to work
> normally, until they might rarely experience the same issue.
>
> When I kill and restart the particular application process , then
> everything is again normal.  So it's that particular process which is
> somehow being refused connection due to < insert solution here >  I
> can't reproduce the problem easily, but once it happens the process
> never recovers.
>
> sun.rmi.transport.tcp.TCPEndpoint.newSocket is where the Connection
> refused originates.  I wonder how I can avoid what appears to be some
> resource limitation problem near TCPEndpoint as in the stack trace
> below (no line numbers).  I'm trying to invoke an RMI method at the
> time of exception.
>
> Java 6 Update 17
>
> java.rmi.ConnectException: Connection
> refused to host: 127.0.0.1; nested exception is:
>        java.net.ConnectException: Connection refused: connect
> java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
> nested exception is:
>        java.net.ConnectException: Connection refused: connect
>        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
>        at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown
> Source)
>        at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown
> Source)
>        at sun.rmi.server.UnicastRef.invoke(Unknown Source)
>        at
> com.twc.remote.RemoteIndicatorServiceImpl_Stub.getAskRunLengthFast(Unknown
> <------- invoking
> Source)
>        at com.twc.trader.TradeEntryManager$AutoTrader.run(Unknown
> Source)
> Caused by: java.net.ConnectException: Connection refused: connect
>        at java.net.PlainSocketImpl.socketConnect(Native Method)
>        at java.net.PlainSocketImpl.doConnect(Unknown Source)
>        at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
>        at java.net.PlainSocketImpl.connect(Unknown Source)
>        at java.net.SocksSocketImpl.connect(Unknown Source)
>        at java.net.Socket.connect(Unknown Source)
>        at java.net.Socket.connect(Unknown Source)
>        at java.net.Socket.<init>(Unknown Source)
>        at java.net.Socket.<init>(Unknown Source)
>        at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown
> Source)
>        at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown
> Source)
>        ... 6 more

From: EJP on 2 May 2010 21:16
On 1/05/2010 1:16 AM, FutureScalper wrote:
>
> Perhaps I need to do this:
>
> sun.rmi.transport.tcp.TCPEndpoint
>
> public static void shedConnectionCaches()
>
> Release idle outbound connections to reduce demand on I/O resources.
> All transports are asked to release excess connections.
>
> Seems to me something is accumulating in this area.

That wouldn't help in the slightest. 'Connection refused' has one
meaning only. Nothing is listening at the target host:port.

Is 127.0.0.1 the expected IP address to connect to?
From: FutureScalper on 6 May 2010 12:46
On May 2, 9:16 pm, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
> On 1/05/2010 1:16 AM, FutureScalper wrote:
>
>
>
> > Perhaps I need to do this:
>
> > sun.rmi.transport.tcp.TCPEndpoint
>
> > public static  void shedConnectionCaches()
>
> > Release idle outbound connections to reduce demand on I/O resources.
> > All transports are asked to release excess connections.
>
> > Seems to me something is accumulating in this area.
>
> That wouldn't help in the slightest. 'Connection refused' has one
> meaning only. Nothing is listening at the target host:port.
>
> Is 127.0.0.1 the expected IP address to connect to?

Well, that can't be the case. There is an RMIRegistry process running
locally and N other apps are bound to it.

Restarting the rmiregistry doesn't help. The client actually has to
be killed and restarted.

Thanks for any other suggestions, as I try and debug this situation
which develops only after some hard usage.

I still think something is accumulating, such as connections, etc., or
some resource.


From: FutureScalper on 6 May 2010 12:57
On May 6, 12:46 pm, FutureScalper <futurescal...(a)gmail.com> wrote:
> On May 2, 9:16 pm, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
>
>
>
>
>
> > On 1/05/2010 1:16 AM, FutureScalper wrote:
>
> > > Perhaps I need to do this:
>
> > > sun.rmi.transport.tcp.TCPEndpoint
>
> > > public static  void shedConnectionCaches()
>
> > > Release idle outbound connections to reduce demand on I/O resources.
> > > All transports are asked to release excess connections.
>
> > > Seems to me something is accumulating in this area.
>
> > That wouldn't help in the slightest. 'Connection refused' has one
> > meaning only. Nothing is listening at the target host:port.
>
> > Is 127.0.0.1 the expected IP address to connect to?
>
> Well, that can't be the case.  There is an RMIRegistry process running
> locally and N other apps are bound to it.
>
> Restarting the rmiregistry doesn't help.  The client actually has to
> be killed and restarted.
>
> Thanks for any other suggestions, as I try and debug this situation
> which develops only after some hard usage.
>
> I still think something is accumulating, such as connections, etc., or
> some resource.

I explicitly use a Java Web Start property to fully specify the
localhost as:
<property name="java.rmi.server.hostname" value="127.0.0.1" />
I also spec the port explicitly, and periodically unbind and rebind
processes.
The convention is XXServer, so, for example
Core.rebindToRemote [rmi://127.0.0.1:1098/YMServer] serverImpl is an
example
of the bind URL for a client. Everything is explicitly specified.
As I said, this thing works for quite a long time, and then under
circumstances
I can't figure out, connection is permanently refused, and I have so
far been unable
to get the Java application client to recover without restart.

But the rmiregistry is there, and running. Now, perhaps it is
refusing connection
to a specific client for some reason, such as an accumulating resource
within
the rmiregistry process itself ?? However, restarting rmiregistry,
and clients
rebinding to it, does not fix the client's connection problems, so I
don't think
that's it.

 |  Next  |  Last
Pages: 1 2 3
Prev: Spam on Usenet groups
Next: Anybody using their Java IDE with the C++ plugin?