Skip to main content

Why do peers fail to communicate after some time?

6 replies [Last post]
Joined: 2006-01-26

I have two edge peers behind different firewalls connecting via a RDV+RLY node that has a public IP. The edge peers use the default edge configuration but with TCP & multicast disabled[their firewall blocks them]:

When the edge peers start they are able to communicate [send data both using bidi pipes and sockets]. However, if I leave them alone for about 5 min and try to send data again, they fail. Even the discovery messages fail. Only a restart of the edge peers allows them to communicate. Note that I do not have to start the RDV-RLY.

After the edge peers fail, on the RDV-RLY peer I get the following warnings:
WARNING: null messenger for dest :jxta://uuid-E00.....
Oct 25, 2009 12:38:45 AM net.jxta.impl.endpoint.router.EndpointRouter cantRoute
WARNING: Failed to deliver or forward message for jxta://uuid-E00..... No reachable endpoints for jxta://uuid-E00.....
at net.jxta.impl.endpoint.router.EndpointRouter.sendOnLocalRoute(
at net.jxta.impl.endpoint.router.EndpointRouter.processIncomingMessage(
at net.jxta.impl.endpoint.EndpointServiceImpl.processIncomingMessage(
at net.jxta.impl.endpoint.EndpointServiceImpl.demux(
at net.jxta.impl.endpoint.EndpointServiceInterface.demux(
at net.jxta.impl.endpoint.servlethttp.HttpMessageServlet.processRequest(
at net.jxta.impl.endpoint.servlethttp.HttpMessageServlet.doPost(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.mortbay.jetty.servlet.ServletHolder.handle(
at org.mortbay.jetty.servlet.ServletHandler.dispatch(
at org.mortbay.jetty.servlet.ServletHandler.handle(
at org.mortbay.http.HttpContext.handle(
at org.mortbay.http.HttpContext.handle(
at org.mortbay.http.HttpServer.service(
at org.mortbay.http.HttpConnection.service(
at org.mortbay.http.HttpConnection.handleNext(
at org.mortbay.http.HttpConnection.handle(
at org.mortbay.http.SocketListener.handleConnection(
at org.mortbay.util.ThreadedServer.handle(
at org.mortbay.util.ThreadPool$
Oct 25, 2009 12:43:58 AM net.jxta.impl.endpoint.router.EndpointRouter$EndpointGetMessengerAsyncListener messengerReady
WARNING: null messenger for dest :jxta://uuid-E007230D135E4C7FB6B287DDCDBFA20BB3903A04BF694A8DB9A7BCE4AE6F96CA03
Oct 25, 2009 12:44:07 AM net.jxta.impl.endpoint.router.EndpointRouter cantRoute
WARNING: No new route to repair the route - drop message
Oct 25, 2009 12:44:15 AM net.jxta.impl.endpoint.router.EndpointRouter cantRoute
WARNING: No new route to repair the route - drop message

I have been banging my head over this for last 3 days and nights. Read all the documentation, read all the forums, but am unable to find a resolution.

Can someone please shed some light on this?

Message was edited by: aimran50

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-10-27

My perdonal experience is the current HTTP implementation can be a bit flakey. oneDrum have implemented a new HTTP full duplex channel transport.

This will be in 2.6 inside the next two weeks.

Joined: 2006-01-26

After another sleepless night I am quite convinced that it is the relay that is misbehaving. I get these errors on the RDV+RLY node. The relay consistently drops the connections in 2-3 minutes.
WARNING: Failed to deliver or forward message for jxta://uuid-E00.... Client has been disconnected
at net.jxta.impl.endpoint.relay.RelayServerClient.queueMessage(
at net.jxta.impl.endpoint.relay.RelayServerClient.access$100(
at net.jxta.impl.endpoint.relay.RelayServerClient$RelayMessenger.sendMessageBImpl(
at net.jxta.impl.endpoint.BlockingMessenger.sendIt(

[b]Are there any relay settings that can be controlled?[/b]
[b]Has any one ever successfully used relay's with NATd edge peers?[/b]

Since I am able to transfer files in the first few minutes, it seems taht this is some defect in JXTA's relay implementation. At this point my frustration is such that I am very close to abandoning JXTA.

Joined: 2007-08-17

aimran50 ,

We use HTTP only at this time also. Waiting for 2.6 to play with TCP also. Enabling TCP behind firewalls didn't work for me, as the RDV outside the network tried to communicate using TCP with the firewalled peers, which led to errors.

Indeed, we experienced the problems of pipes closing or misbehaving. I think the firewall/router was closing connections or something.
The first solution was to have a heartbeat messaging on the pipe, to keep it alive. (sending dummy messages every minute). This can lead to network congestion.
Second was to close the pipe after 2 minutes of inactivity, and reopen it on demand.

Good luck,

Joined: 2008-10-27

Hi TCP from behind firewalls does work. However, you need to change to not accept TCP incoming and to use a relay. This config definately works for us.

I think going forward we need more predefined configurations to make this easier for others to pick up.

Joined: 2007-08-17

Hi John,

Thanks for the tip.
I'll give it a try.
Is this config suitable for 2.6? Or to be clear, is 2.6 bringing something new regarding HTTP/TCP config?

Some thoughts: disabling TCP/parts of TCP is not very nice, since a user having a laptop can move from NAT areas to open internet. Disabling TCP to be sure the app works behind NAT induces more HTTP traffic and more Relays needed.
I hope STUN will be available in the future versions and the config will plugandplay. :)

Joined: 2006-01-26

I did some more tests. I ran both edge peers but this time without using any pipes or sockets. The peers are able to connect to the RDV+RLY peer and respond to "getRemoteAdvertisements" when they start, so I am assuming my seeding and other settings are correct.

However this works only for few minutes. Both edge peers seem to loose connectivity, after 2-3 minutes of idle time, with the RDV+RLY peer and fail to receive any discovery events. This is very consistent.

Did anyone encounter same or similar issue? Is there any resolution or is this a known bug/issue in JXTA?