Re: Connection Refused Exceptions

Bob Scheifler wrote:
>> Sometimes after the restart I
>> will get the following sort of Exception:
>
> Can you provide the complete stack trace (don't SNIP)?

 From some test code:

MessageSendingException: There was an error
         at
uk.co.calicojack.jackdaw.agent.tld.RemoteAgentSemanticsEnforcer.send(RemoteAgentSemanticsEnforcer.java:88)
         at
jackdaw.agent.core.AbstractRemoteAgent.send(AbstractRemoteAgent.java:88)
         at
jackdaw.agent.core.AbstractRemoteAgent.send(AbstractRemoteAgent.java:79)
         at
jackdaw.agent.core.AbstractRemoteAgent.send(AbstractRemoteAgent.java:51)
         at
uk.co.calicojack.jackdaw.examples.pingpong.MessageHandlingPingPongModule$1.execute(MessageHandlingPingPongModule.java:153)
         at
uk.co.calicojack.jackdaw.agent.events.EventProcessorImpl.executeActions(EventProcessorImpl.java:65)
         at
uk.co.calicojack.jackdaw.agent.events.EventProcessorImpl.handleEvent(EventProcessorImpl.java:55)
         at
uk.co.calicojack.jackdaw.agent.tld.NotificationTaskThread.execute(NotificationTaskThread.java:102)
         at
uk.co.calicojack.jackdaw.util.resourcemgmt.TaskThread.run(TaskThread.java:33)
         at java.lang.Thread.run(Thread.java:619)
Caused by: java.rmi.ConnectException: Connection refused to host:
192.168.0.205; nested exception is:
         java.net.ConnectException: Connection refused
         at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
         at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
         at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
         at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110)
         at
uk.co.calicojack.jackdaw.agent.tld.AgentBackend_Stub.sendACLMessage(Unknown
Source)
         at
uk.co.calicojack.jackdaw.agent.tld.JiniServiceProxy.sendMessage(JiniServiceProxy.java:112)
         at
uk.co.calicojack.jackdaw.agent.tld.RemoteAgentSemanticsEnforcer.send(RemoteAgentSemanticsEnforcer.java:80)
         ... 9 more
Caused by: java.net.ConnectException: Connection refused
         at java.net.PlainSocketImpl.socketConnect(Native Method)
         at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
         at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
         at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
         at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
         at java.net.Socket.connect(Socket.java:519)
         at java.net.Socket.connect(Socket.java:469)
         at java.net.Socket.<init>(Socket.java:366)
         at java.net.Socket.<init>(Socket.java:179)
         at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
         at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
         at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
         ... 15 more

>> I am using the ServiceDiscoveryManager and the LookupCache, and I call
>> discard() when I get an exception.  However, after the discardWait when
>> the services are rediscovered the communication also fails with the same
>> error, leading to a cycle of repeated discards, rediscovery, and
>> ConnectExceptions.
>
> I take it the cycle never terminates on its own?

Yes, that's correct the cycle doesn't terminate.

>
>> However, upon
>> restart my services all register back with the lookup service through
>> the JoinManager.
>
> Have you verified that they are in fact replacing their old registrations,
> and not just adding in new registrations, leaving the old ones in place
> until their leases expire?

I'm pretty sure that they should be replacing their old registrations as
I am using the JoinManager to do this:

if(serviceIdSet) {
        joinManager = new
JoinManager(serviceProxy,entries,serviceID,discoveryManagement,leaseRenewalManager);
} else {
        joinManager = new JoinManager(serviceProxy,entries,new
ServiceIdRecorder(),discoveryManagement,leaseRenewalManager);
         }

I construct the JoinManager differently depending on whether or not we
already have a serviceId loaded from the disk.  The ServiceIdRecorder is
obviously responsible for saving this when a service starts for the very
first time.

The only thing that might be a tad unusual here is that the entries
array at this point is null.  This is primarily because our code
requires the serviceId to be set before some of our entries are known.
There's a possibility I could remove this requirement, if this is
causing the problem, but to do so might be quite tricky.  I've checked
JoinManagers source, and it converts nulls into an empty array of
Entries so I don't think it's a problem and worth the effort changing.

--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]