Skip to Content »

Tech Life of Recht » Fun with JXTA

 Fun with JXTA

  • October 26th, 2009
  • 10:46 pm

Recently, I've been messing around with JXTA - one of the things you might have heard about at some point (like JINI, for example), but never really given any thought to. Probably rightly so, because it's only interesting if you do any kind of P2P. And not just human peers.

Anyways, we're planning on using JXTA to create a distributed version of one of our big monolithic systems. The data model has been modified to support distribution, and we've had a prototype running with hardcoded communication channels. However, JXTA makes everything much more dynamic, and it also introduces the concept of rendezvous and relay nodes so all nodes don't have to be on the same network - they don't even have to connect to each other directly. Pretty sweet stuff.

It turns out, however, that the JXTA documentation really doesn't explain everything, so I have two things I want to share - not that I expect them to be useful to very many people.

The first thing is really just a problem rather than a solution. I develop on a nice Macbook Pro Santa Rosa. I don't particularly like Apple (as in not at all, actually. Developer-wise, they might even be higher on the hate-list than Microsoft), so I've removed OSX entirely and installed Ubuntu instead. Now you might ask why I then use a Macbook at all, but it turns out that they make pretty good hardware, so I go with that. Incidentally, I also have an iMac at home, also running Ubuntu. It turns out that this is a problem in one single regard: When I have the wireless network enabled and start a JXTA application, the kernel will freeze. Every time. And there will be no errors in any log files. Nothing bad happens if I use wired network or a 3G modem - which is my solution until now. Of course, it seems that nobody in the whole world has ever had this problem, so there's not much chance of getting it fixed (and where do you report such a bug?).

The other thing that's been consuming quite a lot of my time is JXTASockets. JXTASockets are basically regular Java sockets running over JXTA. Instead of connecting to a specific host on a specific port, you simply ask JXTA to give you a socket to an abstract host identifier. JXTA will then route the request to the appropriate host, and then you can send and receive data. Except for the connect phase, it works just like a normal socket. Except not entirely. In many cases you would do something like on the server side:

  1. JXTAServerSocket server = new JXTAServerSocket(...);
  2. while (true) {
  3.   JXTASocket socket = server.accept();
  4.   InputStream is = socket.getInputStream();
  5.   OutputStream os = socket.getOutputStream();
  7.   int b = -1;
  8.   while ((b => -1) {
  9.     // buffer bytes
  10.   }
  11.   is.close();
  13.   byte[] res = handleRequest(buffer);
  14.   os.write(res);
  15.   os.close();
  16.   socket.close();
  17. }

And on the client side something like this:

  1. Socket socket = new JXTASocket(...);
  2. InputStream is = socket.getInputStream();
  3. OutputStream os = socket.getOutputStream();
  5. os.write(generateRequest());
  6. os.close();
  8. readResponse(is);
  9. is.close();
  10. socket.close();

Of course, all sorts of error handling, buffering, and other stuff is missing, but the overall procedure should be clear: the client writes to the output stream and closes it. The server reads from the stream until it has been closed. The server then generates a response and writes it back. Add the appropriate resource handling, and this will work using normal sockets, but it will not work with JXTA. And no, it is not obvious why. In fact, I think the plot of "A Serious Man" is more obvious, and if you've seen the movie, you'll probably agree with me that it is, indeed, not obvious at all.
The problem with JXTA turns out to be that both streams must be open all the time. If you, for example, close the output stream on the client side to signal that there is no more data, the server side will simply get a read timeout at some point. This basically means that you cannot use a closed stream to signal the end of the data stream, so instead you have to write the data length to the stream first, and then the data. The receiving side can then read the data length first, and then read the actual data accordingly. Which is not bad, it just sucks when you've spent so many hours debugging that read timeout.

7 People had this to say...


Good work! I would look forword your article. Maybe you can come to my website to search what you need~

welcome everyone come to my website!


Your post title is usually Liz coupled with I’ve some strategy.


Great minds think alike.

  • Vision
  • January 24th, 2013
  • 10:45 am

There are plenty of blogs on the same topic but your blog is different and more informative.


This is an awesome blog and a great source to get updated by some of the greatest facts.


I was very happy that I found this site. I needed to thank you for this excellent information!

Thanks! I’ll not press JXTA to relicense, but I agree that ASL v2 is indeed state-of-the-art in BSD-style licensing.

Want your say?

* Required fields. Your e-mail address will not be published on this site

You can use the following XHTML tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>