Skip to main content

Message send failed for net.jxta.endpoint.Message

19 replies [Last post]
samantha001
Offline
Joined: 2008-09-09
Points: 0

Hi all,

I am using sockets for transferring file, whenever i am trying to download large file in a private connection(using Relay) getting the error:

Feb 25, 2009 3:44:28 PM net.jxta.impl.endpoint.tcp.TcpMessenger sendMessageDirec
t
WARNING: Message send failed for net.jxta.endpoint.Message@15771477(4){27159}
java.net.SocketTimeoutException: Failed sending net.jxta.endpoint.Message@157714
77(4){27159} to : 75.127.91.122:9701
at net.jxta.impl.endpoint.tcp.TcpMessenger.xmitMessage(TcpMessenger.java
:645)
at net.jxta.impl.endpoint.tcp.TcpMessenger.sendMessageDirect(TcpMessenge
r.java:549)
at net.jxta.impl.endpoint.tcp.TcpMessenger.sendMessageBImpl(TcpMessenger
.java:520)
at net.jxta.impl.endpoint.BlockingMessenger.sendIt(BlockingMessenger.jav
a:802)
at net.jxta.impl.endpoint.BlockingMessenger.performDeferredAction(Blocki
ngMessenger.java:755)
at net.jxta.impl.endpoint.BlockingMessenger.sendMessageB(BlockingMesseng
er.java:621)
at net.jxta.impl.endpoint.BlockingMessenger$BlockingMessengerChannel.sen
dMessageB(BlockingMessenger.java:337)
at net.jxta.impl.endpoint.router.EndpointRouter.sendOnLocalRoute(Endpoin
tRouter.java:622)
at net.jxta.impl.endpoint.router.RouterMessenger.sendMessageBImpl(Router
Messenger.java:178)
at net.jxta.impl.endpoint.BlockingMessenger.sendIt(BlockingMessenger.jav
a:802)
at net.jxta.impl.endpoint.BlockingMessenger.performDeferredAction(Blocki
ngMessenger.java:755)
at net.jxta.impl.endpoint.BlockingMessenger.sendMessageB(BlockingMesseng
er.java:621)
at net.jxta.impl.endpoint.EndpointServiceImpl$CanonicalMessenger.sendMes
sageBImpl(EndpointServiceImpl.java:453)
at net.jxta.endpoint.ThreadedMessenger.send(ThreadedMessenger.java:491)
at net.jxta.endpoint.ThreadedMessenger.run(ThreadedMessenger.java:385)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketTimeoutException: Timeout during socket write
at net.jxta.impl.endpoint.tcp.TcpMessenger.write(TcpMessenger.java:732)
at net.jxta.impl.endpoint.tcp.TcpMessenger.xmitMessage(TcpMessenger.java
:627)
... 15 more
Feb 25, 2009 3:44:29 PM net.jxta.impl.endpoint.tcp.TcpMessenger closeImpl
WARNING: Failed to close messenger net.jxta.impl.endpoint.tcp.TcpMessenger@d88d2
d {tcp://75.127.91.122:9701}
java.io.IOException: A non-blocking socket operation could not be completed imme
diately
at sun.nio.ch.SocketDispatcher.close0(Native Method)
at sun.nio.ch.SocketDispatcher.preClose(Unknown Source)
at sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(Unknown Sourc
e)
at java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(Unkn
own Source)
at java.nio.channels.spi.AbstractInterruptibleChannel.close(Unknown Sour
ce)
at net.jxta.impl.endpoint.tcp.TcpMessenger.closeImpl(TcpMessenger.java:4
49)
at net.jxta.impl.endpoint.tcp.TcpMessenger.sendMessageDirect(TcpMessenge
r.java:554)
at net.jxta.impl.endpoint.tcp.TcpMessenger.sendMessageBImpl(TcpMessenger
.java:520)
at net.jxta.impl.endpoint.BlockingMessenger.sendIt(BlockingMessenger.jav
a:802)
at net.jxta.impl.endpoint.BlockingMessenger.performDeferredAction(Blocki
ngMessenger.java:755)
at net.jxta.impl.endpoint.BlockingMessenger.sendMessageB(BlockingMesseng
er.java:621)
at net.jxta.impl.endpoint.BlockingMessenger$BlockingMessengerChannel.sen
dMessageB(BlockingMessenger.java:337)
at net.jxta.impl.endpoint.router.EndpointRouter.sendOnLocalRoute(Endpoin
tRouter.java:622)
at net.jxta.impl.endpoint.router.RouterMessenger.sendMessageBImpl(Router
Messenger.java:178)
at net.jxta.impl.endpoint.BlockingMessenger.sendIt(BlockingMessenger.jav
a:802)
at net.jxta.impl.endpoint.BlockingMessenger.performDeferredAction(Blocki
ngMessenger.java:755)
at net.jxta.impl.endpoint.BlockingMessenger.sendMessageB(BlockingMesseng
er.java:621)
at net.jxta.impl.endpoint.EndpointServiceImpl$CanonicalMessenger.sendMes
sageBImpl(EndpointServiceImpl.java:453)
at net.jxta.endpoint.ThreadedMessenger.send(ThreadedMessenger.java:491)
at net.jxta.endpoint.ThreadedMessenger.run(ThreadedMessenger.java:385)
at java.lang.Thread.run(Unknown Source)
Feb 25, 2009 3:44:29 PM net.jxta.impl.endpoint.tcp.TcpMessenger closeImpl
INFO: Normal close (open 24205ms) of socket to : tcp://75.127.91.122:9701 / 75.1
27.91.122:9701
Feb 25, 2009 3:44:29 PM net.jxta.impl.endpoint.tcp.TcpMessenger
INFO: Creating new TCP Connection to : tcp://75.127.91.122:9701 / 75.127.91.122:
9701
Sending a Discovery Message

Please provide some solution else i have to close the project.

Thanks in Advance :)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aimran50
Offline
Joined: 2006-01-26
Points: 0

Did this actually work for you? I have the similar settings as you do, but a different tcp port.

The telnet test or the browser test returns the JXTAHELLO message tcp://m.n.o.p. It does not show the port after the tcp://. Which I am guessing is taking port 80 for some reason.

However if I comment out the setTcpPublic... lines, I get a JXTA response with a tcp://localip:myport. It shows the configured port against the local IP

Why is it picking port 80 even when I set a specific port?

=======
My code...
config.setTcpEnabled(true);
config.setTcpIncoming(true);
config.setTcpOutgoing(true);
if (TcpPort != -1) {
config.setTcpPort(TcpPort);
}
config.setTcpStartPort(-1);
config.setTcpEndPort(-1);

config.setTcpInterfaceAddress(internalIP);
config.setTcpPublicAddress(externalIP, false);

config.setHttpEnabled(true);
config.setHttpIncoming(true);
config.setHttpOutgoing(true);
if (HttpPort != -1) {
config.setHttpPort(HttpPort);
}

enygma2002
Offline
Joined: 2008-12-22
Points: 0

It's probably because your intarnalIp and externalIp variables contain something in the format "m.n.o.p".

The javadoc for the config.setTcpInterfaceAddress method requires a value in the format "m.n.o.p" but the javadoc for the config.setTcpPublicAddress method requires a value in the format "m.n.o.p:port".

It's probably not picking port 80. It probably is a value that is not checked in the jxta side and it got in the advertisement in an invalid way, making that destination unreachable. (?) If so, it should be checked in future versions of jxta.

P.S.: I figure that config.setTcpPort(TcpPort); is for internal use only. The port specified at the externalIp can be different (when port forwarding is enabled). You have to take this into consideration as well.

Good luck!

aimran50
Offline
Joined: 2006-01-26
Points: 0

Thank you for your response enygma2002. Your solution ("m.n.o.p:port") worked. I was missing the port.

subvault
Offline
Joined: 2005-02-15
Points: 0

Any further insight from anyone on this would be appreciated.

I'm seeing almost exactly the same error, also using tcp only for relay (no http). Testing on a local network (with multicast off) through a local relay we are able to transfer arbitrarily large files without issue. But as soon as the relay is outside the lan we see this issue. All other messages are transferring correctly.

Does anyone know if anything is different for messaging of this type? Noticing this:

[i]net.jxta.impl.endpoint.tcp.TcpMessenger sendMessageDirect[/i]

Makes me think it's actually trying to connect from the relay directly back to the receiving peer which will obviously fail due to NAT addressing.

Has anyone seen success on this with http relays?

Cheers,
Ian

subvault
Offline
Joined: 2005-02-15
Points: 0

Managed to resolve the immediate issue that I was seeing, posting back in case it's useful for the original problem and for newcomers.

My local tests were succeeding and although they were passing through a relay/rendezvous peer the traffic was all local. When pushing the code to a test environment the data was failing to send. On closer inspection it was down to the configuration of my super peer.

The test environment had an internal ip and a NAT'd external public IP. This meant that when issuing a cmd (from outside the superpeer network) such as:

[i]> telnet w.x.y.z 7000[/i]
(where w.x.y.z is the public ip of super peer)

I got a response along the lines of

[i]JXTAHELLO tcp://a.b.c.d:37800 tcp://m.n.o.p:7000 urn:jxta:uuid-abcdef1234567890... 0 1.1[/i]

Where a.b.c.d is my local external ip and m.n.o.p is the relays internal ip. This in turn meant that my connection back to the relay was not resolvable as it was using the internal ip.

I've now changed the configuration of the super peer to:

[b]NetworkConfigurator configurator = networkManager.getConfigurator();
configurator.setUseMulticast(false);
configurator.setTcpStartPort(-1);
configurator.setTcpEndPort(-1);
configurator.setTcpEnabled(true);
configurator.setTcpPort(7000);
configurator.setTcpInterfaceAddress("m.n.o.p");
configurator.setTcpPublicAddress("w.x.y.z", false);[/b]

Setting start and end ports to -1 was needed to solve the following exception:

[i]java.lang.IllegalStateException: Dynamic ports not supported with public address port forwarding.[/i]

Hope this info is of use to others.

Cheers,
Ian

samantha001
Offline
Joined: 2008-09-09
Points: 0

Hi,
By setting the tcpsatart and end port, your problem has been solved of disconnection?
Can you please tell me the architecture of your application.
Really i need this information.

Thanks in advance.

subvault
Offline
Joined: 2005-02-15
Points: 0

Hi,

Our issue wasn't so much about disconnection, we were seeing the same top level exception as this post starts with:

WARNING: Message send failed for net.jxta.endpoint.Message@15771477(4){27159}
java.net.SocketTimeoutException: Failed sending net.jxta.endpoint.Message@157714
77(4){27159} to : 75.127.91.122:9701
at net.jxta.impl.endpoint.tcp.TcpMessenger.xmitMessage(TcpMessenger.java
:645)
at net.jxta.impl.endpoint.tcp.TcpMessenger.sendMessageDirect(TcpMessenge
r.java:549)
at net.jxta.impl.endpoint.tcp.TcpMessenger.sendMessageBImpl(TcpMessenger
.java:520)

In our case that was caused by the relay advertisement giving the internal ip of our server. Changing as in my previous post to set the public address solved that. However then we began getting exceptions about 'ava.lang.IllegalStateException: Dynamic ports not supported with public address port forwarding.'

From google it seemed that dynamic ports are used to form the endpoints upon which connections come back in on. So setting the start and end ports to -1 disables dynamic port usage. As we have limited control over the NAT routing on the deployment server this ensures the ports being used are accessible to connecting clients.

Our current architecture is pretty basic right now:

1) Central relay/rdv peer running upon Amazon EC2 (which is NAT'd)
2) Multiple edge peers which run from work/home networks

We only use tcp relay seeds currently (http and multicast are disabled) but are planning to enable these once we have the basics rock solid.

Hope that helps clarity,
Ian

samantha001
Offline
Joined: 2008-09-09
Points: 0

Hi,
Thnx, Ok so my all basics was right. Now i have to test just by setting Tcpstartport and endport by -1.
i Hope this will work for me. I was geeting the error of socket linger and nio clashing at the time of transferring file on wan but after using latest nightly build, this problem has been solved for windows but still coming for linux machines. Have you tested this on linux machines or your applcation is running smoothly or not currently.

Thanks 1ce again.

subvault
Offline
Joined: 2005-02-15
Points: 0

Haven't tested explicitly on linux, though our relay/rdv peer is on linux. Main development is on a mac and testing on windows via VMWare.

Also for information: We're not currently running with the nightly build just the standard 2.5 build. Currently we're not seeing any big issues and it seems pretty stable. But we are still performing more tests and need to carry out more in depth load tests.

samantha001
Offline
Joined: 2008-09-09
Points: 0

ok, Can you please do a favor for me. Please look once my configuration above, anything i am doing wrong in that. If you find anything wrong then please tell me.
Can u please provide me your configuration file so i can match up with my file, if its possible for you.
I am so thankful.

subvault
Offline
Joined: 2005-02-15
Points: 0

Hi,

The only difference I see is that we set tcp incoming to false on the 'client' peers. This should mean that they don't advertise an incoming port (which in our case would typically be firewalled). Instead they would connect to the relay and receive messages through that connection.

My understanding is that this essentially polls the relay (if the connection is closed) to retrieve new messages/advertisements. However I could well be wrong on the detail of this.

Of course depending upon your environment and usage you may need the incoming.

We also have multicast disabled currently as it was giving too many false positives, i.e. local testing works perfectly then fails in the deployed environment. Multicast seems almost too easy to get functional, was working way before we were ready for it.

Ian

enygma2002
Offline
Joined: 2008-12-22
Points: 0

I am also having trouble with this and have found that setting the TCPincomming or HTTPIncomming to false to a joining peer is the solution.

This makes your assumptions correct about the peer advertising it's input port that was firewalled.

If this is the case, how can a firewalled peer that wants to join a network also be rendezvous/relay for that network serving for peers inside it's LAN/subLANs ? (to handle network load, etc.)

If the joining peer needs to set TCPincomming and/or HTTPIncomming to false, then how can it accept any other connections from peers inside it's LAN? As far as I understand, this makes communication strictly dependent to the relay, peers not being able to specify that "for relay, disable TCPincomming, but for my rendezvous role keep it enabled so I can accept new connections and redirect them to the relay or something similar".

What is there to do if one wishes to add such peers (local rendezvous, but edges for the remote and bigger network)?

jonahclint
Offline
Joined: 2010-03-03
Points: 0

I had the same problem with my easy saver program. I never quite managed to sort it out until reading this thread. Thanks a lot for your answers.

felbinac
Offline
Joined: 2008-10-02
Points: 0

Although you said to use a Relay Peer, but there are not any HTTP transferring in the log messages. I wonder why...

samantha001
Offline
Joined: 2008-09-09
Points: 0

not using http and configuring jxta like this :

PeerGroupID NetPeerGroupID = (PeerGroupID )IDFactory.fromURI(new URI("urn:jxta:uuid-8B33E012995678918BF9A446A224B16F02"));
NetworkManager TheNetworkManager = new NetworkManager(NetworkManager.ConfigMode.EDGE,p.getUserName());
// Persisting it to make sure the Peer ID is not re-created each
// time the Network Manager is instantiated
TheNetworkManager.setConfigPersistent(true);
TheNetworkManager.setUseDefaultSeeds(false);
//TheNetworkManager.setInfrastructureID(NetPeerGroupID);
System.out.println("Retrieving the Network Configurator");
try {
TheConfig = TheNetworkManager.getConfigurator();
} catch (IOException e) {
e.printStackTrace();
}

if (TheConfig.exists()) {

System.out.println("Local configuration found");
// We load it
File LocalConfig = new File(TheConfig.getHome(), "PlatformConfig");
try {
System.out.println("Loading found configuration");
TheConfig.load(LocalConfig.toURI());
System.out.println("Configuration loaded");
} catch (IOException ex) {
ex.printStackTrace();
System.exit(-1);
} catch (CertificateException ex) {
// An issue with the existing peer certificate has been encountered
ex.printStackTrace();
System.exit(-1);
}
} else {
System.out.println("No local configuration found");
TheConfig.setName(p.getUserName());

TheConfig.setPrincipal(p.getUserName());
TheConfig.setPassword(p.getPass());
TheConfig.setDescription("Hypeset Config");
//String seed = p.getUserName() + SEED;

//TheConfig.setInfrastructureName("Hypeset");
TheConfig.setInfrastructureID(NetPeerGroupID);
TheConfig.setPeerID(IDFactory.newPeerID(NetPeerGroupID));
// URI seedingURI = new File("seeds.txt").toURI();
String ip="tcp://75.127.91.122:9701";
URI seedingURI = URI.create(ip);
TheConfig.addSeedRelay(seedingURI);
TheConfig.addSeedRendezvous(seedingURI);
// TheConfig.addRdvSeedingURI(seedingURI);
// TheConfig.addRelaySeedingURI(seedingURI);
//TheConfig.setRendezvousSeedingURIs((p.getRend()));
//TheConfig.setRelaySeedingURIs((p.getRelay()));
//TheConfig.setTcpPublicAddress(p.getRelay(),true);
TheConfig.setUseOnlyRelaySeeds(true);
TheConfig.setUseOnlyRendezvousSeeds(true);
TheConfig.setTcpPort(9701);
TheConfig.setTcpEnabled(true);
TheConfig.setTcpIncoming(true);
TheConfig.setTcpOutgoing(true);

try {
System.out.println("Saving new configuration");
TheConfig.save();
System.out.println("New configuration saved successfully");
} catch (IOException ex) {
ex.printStackTrace();
System.exit(-1);
}
}

is it anything wrong or missing?

felbinac
Offline
Joined: 2008-10-02
Points: 0

In the same situation, can MyJxta transfer/receive your files ?

samantha001
Offline
Joined: 2008-09-09
Points: 0

DIDNT TRY

felbinac
Offline
Joined: 2008-10-02
Points: 0

Do you break up large files into pieces to send ?

samantha001
Offline
Joined: 2008-09-09
Points: 0

Yes, breaking the files into chunks and then sends just like myjxta file sender.