Pandemonium Medicine ShowWeblog of Mike Duigouhttps://blogs.oracle.com/bondolo/feed/entries/atom2014-01-29T05:30:17+00:00Apache Rollerhttps://blogs.oracle.com/bondolo/entry/the_new_jxta_bookThe New JXTA Bookmduigou 2008-10-07T11:56:00+00:002008-10-07T18:56:00+00:00My copy of the recently published, <i><a href="http://practicaljxta.com">Practical JXTA</a></i>, arrived the other day. I have been thumbing through it <a href="http://xkcd.com/303/">during compiles</a>. I haven't yet had time to read in detail more than the introduction, table of contents and the author bio.
<p/>
Looking at the table of contents it appears that the book hits exactly the points that have traditionally (or recently) caused developers confusion and pain as they are learning JXTA. It also really helps that the book is based upon the latest JXSE 2.5 release. Some of the code shown in older books no longer compiles properly with the latest releases (and some of it I'm pretty sure <i>never</i> compiled). JXTA has evolved and improved a lot over the years and without new editions the older JXTA books, or at least their code examples, have become obsolete. Learning JXTA with a new up-to-date book should be a lot easier.
<p/>
I'm looking forward to reading the entire book when I get the time.https://blogs.oracle.com/bondolo/entry/2008_edsger_w_dijkstra_prize2008 Edsger W. Dijkstra Prize Papermduigou 2008-08-18T12:22:25+00:002008-08-18T19:22:25+00:00I saw <a href="http://hnr.dnsalias.net/wordpress/?p=50">mention</a> today of the <a href="http://www.podc.org/dijkstra/2008.html
">2008 Edsger W. Dijkstra Prize</a>. The winner was a 1990 paper which I remember reading and discussing in the early days of JXTA. The relevance to JXTA was in how it helped routing and validated P2P multihop routing as being capable of near optimal performance.
<p align="center"><table width="80%" bgcolor="F0F0F0">
<caption>
<b><a href="http://hnr.dnsalias.net/wordpress/?p=50">PaperTrail</a> Summary:</b>
</caption>
<tbody>
<tr><td style="padding: 1em">
...there are efficient ways of constructing clustered representations of graphs that remain within a small factor of the original in terms of route lengths. Further, the authors show that this can be done in a distributed manner. This has lots (and lots) of potential applications - the typical example is for a compact routing scheme, where nodes can store smaller routing tables between clusters rather than between nodes.
</td></tr>
</tbody>
</table>
https://blogs.oracle.com/bondolo/entry/configuring_jxta_podcast_out_ofUnderstanding JXTA Podcast : Out of Gas?mduigou 2008-07-01T12:39:06+00:002008-07-01T19:39:06+00:00Here's another update of the JXTA configuration podcast I've been working on for a couple of months. It's got a few more slides than last time (wow, 2 slides in 2 months!) I also got some great feedback from <a href="http://blogs.sun.com/hamada">hamada</a> which I've tried to incorporate.
<p align="center">
<script type="text/javascript" src="http://pdfmenot.com/embed/?url=http://blogs.sun.com/bondolo/resource/Config_Diagrams_Share.pdf&width=600&height=700"></script>
</p>
<p/>
I'll probably add more slides over the summer and start working on the narration as I get time. Unfortunately, I feel like I've run out of gas on this topic though. I know that the content is not complete (far from complete probably) but I'm at a loss as to what's missing and what's important. I don't believe that the presentation answers the likely questions that users have about JXTA networking and configuration.
<p/>
So, to really get this presentation moving again I need your help. I've asked for and received (thank you!) feedback on the slides a couple of times.
<p/>
To make further progress I need your insights as well as your questions and confusions.
<ul>
<li>What's missing?</li>
<li>What's important?</li>
<li>What's not mentioned?</li>
<li>What's confusing?</li>
<li>What isn't answered?</li>
<li>What's doesn't match what you expected?</li>
</ul>https://blogs.oracle.com/bondolo/entry/configuring_jxta_podcast_updateConfiguring JXTA Podcast Updatemduigou 2008-05-12T14:55:20+00:002008-05-12T21:55:20+00:00With the rush of JavaOne I haven't had much time to update the slides for my planned JXTA configuration podcast. In the last month I've added only 3 new slides and made only a few text updates. I thought it would be worth updating the slides though since I'm now going on vacation for a couple of weeks. Enjoy!
<p/>
<a href="http://blogs.sun.com/bondolo/resource/Config_Diagrams_Share.pdf">JXTA Configuration Podcast Slides</a>https://blogs.oracle.com/bondolo/entry/configuring_jxta_podcastConfiguring JXTA Podcast (not yet)mduigou 2008-04-15T20:32:00+00:002008-04-16T03:32:01+00:00For the last couple of weeks I have been slowly building a presentation for what I eventually hope will be a podcast/talk on JXTA configuration.
<p/>
The presentation isn't about the mechanics (the <i>how</i>) of JXTA configuration but is instead focused entirely at the <i>why</i> of JXTA configuration. I've also been trying to make the presentation as self contained as possible, a reader or (eventually) a listener shouldn't need to have any prior understanding of JXTA's inner workings in order to make sense of what is discussed. I've been somewhat unsure about what level of experience with networking should be assumed though. Should I assume that readers know what a firewall is? Should I assume that they know that SMTP is used for sending email messages? Should I assume that readers know the RFC numbers and port assignments for the 100 most common network protocols? (Just kidding).
<p/>
A week ago I asked a few people for feedback on the presentation to make sure I was going the right direction. The responses I got were very encouraging. In the last week I've prepared eight additional slides and I'm still enthusiastic that when completed this podcast will help many starting JXTA configurators. I've decided to start posting my drafts of the work in progress. I'll try to post an updated draft every week or so until the podcast is released. My primary goal in posting drafts is to make sure that the material remains on the right track. I'm interested in hearing feedback. I'm not too concerned, right now, with minor "There's a typo on slide 9, netowrk" type of errors. I'd rather hear about "You never explain what a peer is", kind of errors. (By the way, I guess I need to make a "What is a peer" slide....)
<p/>
The current slide presentation with notes : <a href="http://blogs.sun.com/bondolo/resource/Config_Diagrams_Share.pdf">JXTA Configuration</a>https://blogs.oracle.com/bondolo/entry/jxta_jxse_2_5_releasedJXTA JXSE 2.5 Released!mduigou 2007-11-07T15:20:33+00:002007-11-07T23:20:33+00:00At long last JXSE 2.5 "Turducken" is now finally released. It was a huge amount of work and I believe it's going to be a very significant milestone for the JXSE community. I've still got a few more "What's Cool About JXSE 2.5" blogs to write (there's so much that's cool) but now it's out and there is no reason for any JXTA developer to not be using it. I'm really thrilled with the number of people and companies that have contributed to JXSE over the last year. I very much hope that our community can continue to grow and take this amazing networking technology to all kinds of new places!https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_s6JXSE 2.5 : What's Cool #7 -- Loggingmduigou 2007-10-14T12:37:28+00:002007-10-14T19:37:28+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>
One of the first major changes to occur in the JXSE 2.5 development cycle was our transition from Log4J to <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/package-summary.html">java.util.logging</a></tt>. I previously blogged <a href="http://blogs.sun.com/bondolo/entry/log4j_to_java_util_logging">here</a> how we used Jackpot to do the conversion between the two APIs. The instigator of our transition to use <tt>java.util.logging</tt> was the Shoal project. Since all of Glassfish already used <tt>java.util.logging</tt> they quite reasonably didn't want a second logging framework, Log4J, in order to use JXTA. This concern has been an occasional, but common, observation by JXTA deployers ever since <tt>java.util.logging</tt> first appeared in JDK 1.4. We've planned on changing to <tt>java.util.logging</tt> "eventually" for quite a while. The gentle nudge, and the offer of testing assistance from the Shoal, finally made doing the conversion a priority.
<p/>
Following the conversion to <tt>java.util.logging</tt> the JXSE community has struggled a bit with the transition. The control mechanisms for <tt>java.util.logging</tt> are somewhat different from the Log4J controls and certainly not as familiar. Most of the initial bumps have smoothed out over the last nine months as the wikis, FAQs and mailing list archives have accumulated our increasing experience with <tt>java.util.logging</tt>.
<p/>
As with any significant change there are inevitably comprises. Leaving Jog4J meant we lost the use of Chainsaw though we gained significantly with the availability of a wide variety of JMX tools.
<p/>
During the entire life of the JXSE project we've regularly received requests to entirely disable logging including permanently disabling logging by removing it from the compiled code. Generally the request is made for two reasons; to reduce the size of the JXSE jar or to make it harder for end users to disassemble proprietary JXTA-based applications. With the change to <tt>java.util.logging</tt> it is now possible to selectively disable logging. The instructions are available as part of the JXSE 2.5 Javadoc (Which will be <a href="https://jxta-docs.dev.java.net/nonav/jxse-javadoc/current/jxse/api/net/jxta/logging/package-summary.html">here</a> once the page is updated for JXSE 2.5). https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_s5JXSE 2.5 : What's Cool #6 -- PeerGroup Executor and ScheduledExecutormduigou 2007-10-09T10:31:25+00:002007-10-14T18:23:48+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific APIs, and most significantly the new <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html">java.util.concurrent</a></tt> utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.
<p/>The concurrency utilities provide several flavours of task executors. The <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.html">Executor</a></tt> and <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ScheduledExecutor.html">ScheduledExecutor</a></tt> classes provide a convenient way to execute tasks without the overhead of the normal Thread lifecycle. For JXSE the use of <tt>Executor</tt> is a very good fit. There are a very large number of short lived operations or tasks that JXSE performs to maintain the JXTA network and to handle application I/O. JXSE currently makes fairly heavy use of <tt>Timer</tt> for periodic maintenance tasks. We expect that in future JXSE releases we will replace all of the <tt>Timer</tt> usage with <tt>ScheudledExecutor</tt>.
<p/>One difficulty we have found with <tt>Executor</tt> is that the default policy is not well suited to I/O frameworks. The standard policy uses a fixed base number of threads and a fixed size queue. If the queue fills then additional threads are started to a fixed maximum. The policy that would work best for JXSE and other I/O driven systems is a fixed base number of threads and a fixed size queue. Additional threads would be started for additional tasks to a fixed maximum. After that tasks would be queued to a fixed maximum at which point the task submitters would block until their tasks could be enqueued or executed. The effect of the default policy is that when the base of Threads are occupied new tasks will be started with much higher latency unless the system is entirely saturated with tasks.
<p/>The <tt>Executor</tt> interface does allow some policy to be controlled, but we haven't really figured out how to effectively override the standard policy. Suggestions and or contributions would, of course, be very welcome!
https://blogs.oracle.com/bondolo/entry/wireshark_jxta_support_updatedWireshark JXTA Support Updatedmduigou 2007-10-04T18:15:41+00:002007-10-05T01:15:54+00:00A few days ago I committed an update to the JXTA Wireshark dissector. This updated version provides better HTTP dissection and adds additional addressing information for the dissected packets. The additional addressing information allows for more filtering choices and more fields for generating graphs. https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_s4JXSE 2.5 : What's Cool #5 -- java.util.concurrentmduigou 2007-09-20T11:50:46+00:002007-09-20T21:04:59+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific APIs, and most significantly the new <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html">java.util.concurrent</a></tt> utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.
<p/>The use of the <tt>java.util.concurrent</tt> package, also known as the <a href="http://g.oswego.edu/dl/concurrency-interest/">JSR-166</a> utilities, within JXSE 2.5 has been primarily about simplifying the implementation, obsoleting use of JXSE private utilities (mostly <tt>net.jxta.impl.util.UnbiasedQueue</tt>) and improving performance by allowing greater concurrency. By making use of the concurrency utilities in JXSE 2.5 the implementation is easier to understand, debug and extend. Use of <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentMap.html">ConcurrentHashMap</a></tt> has been particularly useful in simplifying several areas which where very complicated due to concurrency requirements.
<p/>We have also found the <tt><a href="fhttp://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/package-summary.html">java.util.concurrent.atomic</a></tt> utilities very useful for simplifying code which required atomic counters and atomic booleans. In a few places we have started to use the <tt><a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/package-summary.html">java.util.concurrent.locks</a></tt> utilities and expect that future versions of JXSE will make more use of these utilities.
<p/>The next entry in this series will talk about JXSE 2.5's use of the <tt>java.util.concurrent</tt> <tt>Executor</tt> and <tt>ScheduledExecutor</tt>.https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_s3JXSE 2.5 : What's Cool #4 -- Generics & enumsmduigou 2007-09-13T14:54:23+00:002007-09-14T00:33:37+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>JXSE 2.4 was the first version to require Java Standard Edition 5.0. For that release we used only a small amount of JSE 5 specific functionality. The requirement of JSE 5.0 was primarily about advancing the support matrix to include the then newly released JSE 6 and providing the opportunity to take advantage of new features in future releases. In JXSE 2.4.1 we started to make much greater use of JSE 5.0 specific features. The most obvious examples are the use of Java <a href="http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html">Generics</a> and <a href="http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html">Enums</a>. In JXSE 2.5 we have continued to make greater use of both of these features and each are now used extensively through out the JXSE source. These two features have allowed us to greatly simplify and clarify the JXSE APIs and implementation.
<p/>The common case for Java generics involves being able to write type-safe algorithms which can be applied to any appropriate data-type. The most popular usage of generics is undoubtedly the <a href="http://java.sun.com/javase/6/docs/api/java/util/Collection.html">Java SE Collection</a> utilities. In JXSE 2.5 we have converted virtually all of our usage of the collection classes to make use of the generified versions. For example, where a JXSE API previously returned <tt>Vector</tt> it now likely that it will return <tt>Vector&lt;PeerID&gt;</tt>. According to Java language rules programs which reference the "raw" Vector type will continue to work.
<p/>There are several advantages to the genericized API. The contents of the result <tt>Vector</tt> are now explicit which makes the API clearer. This is the primary advantage. An obvious API is one which will be used correctly. Programs which use the API can also more easily avoid errors because they can be written with direct reference to the correct types. We've been able to find errors even within JXSE itself where the wrong type was being used. If you have been using older versions of JXSE we think you'll find using the updated versions of the APIs much more convenient and pleasing to use, especially if you use an IDE with code completion.
<p/>JXSE 2.5's use of enums is designed to be compile time compatible in all cases with previous versions of JXSE. Unfortunately, for internal language support reasons, programs which were compiled against 2.4.1 or earlier must be recompiled to use JXSE 2.5. The JXSE libraries have always tried to maintain version-to-version compile-time compatibility though, such as in the case of the conversion to use <tt>enum</tt>, it has not always been possible to maintain runtime compatibility. The primary advantages of using <tt>enum</tt> within JXSE has been to improve clarity and simply usage as well as to take advantage of enum properties such as the ability to use <tt>switch</tt> statements for enum typed variables.
https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_s2JXSE 2.5 : What's Cool #3 -- Programmers Guide 2.5mduigou 2007-09-12T14:30:09+00:002007-09-12T21:30:09+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>One of the most exciting new developments related to JXSE 2.5 is the new edition of the JXSE Programmers Guide that will accompany it's release. <a href="http://blogs.sun.com/hamada">Mohamed Abdelaziz (hamada)</a> began working on updating of the Programmers Guide last summer. Over the past year hamada has been leading the effort to add content, update and improve the existing content and correct hundreds of minor errors in the older Guide editions. Having an updated version of the Guide which matches the current JXSE APIs and best practices makes it much easier to get started with JXSE.
<p/>Throughout the entire process, and indeed for the last two editions of the Guide, Ted Kosan (tkosan) provided review and suggestions. For the new edition Jérôme Verstrynge provided a complete new tutorial as well doing a thorough review of the entire Guide. Kees Pieters and Mike Cumings (mcumings) also provided a complete reviews of the Guide.
<p/>This new edition of the Programmers Guide has been a long time in development. In part, this was because the Guide needed a format conversion and a lot of updates. We'd like to have it updated more frequently with a smaller number of changes in each new edition. The preparing the next edition should take about six months. If you have examples, content or suggestions now would be a great time to get involved. The focus of the next edition will likely be to create more complete write-ups of the new tutorial programs and hopefully new tutorial chapters for Peer Group Services and a replacement Secure Peer Group tutorial. Visit the <a href="https://jxta-guide.dev.java.net">JXTA Programmers Guide</a> project for more information on getting involved with creating the next edition of the Programmers Guide!
<p/>The new edition is available in a number of formats. We are providing <a href="https://guest@jxta-guide.dev.java.net/svn/jxta-guide/trunk/src/guide_v2.5/JXSE_ProgGuide_v2.5.pdf">JXTA JXSE Programmers Guide 2.5</a> (PDF) and <a href="https://guest@jxta-guide.dev.java.net/svn/jxta-guide/trunk/src/guide_v2.5/JXSE_ProgGuide_v2.5.odt">JXTA JXSE Programmers Guide 2.5</a> (ODT) as well as, for the first time as print-on-demand, <a href="http://www.lulu.com/content/1197206">JXTA JXSE Programmers Guide 2.5</a> (print-on-demand@lulu.com)https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_s1JXSE 2.5 : What's Cool #2 -- META-INF/servicesmduigou 2007-09-06T16:12:40+00:002007-09-06T23:12:40+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>One thing that's cool about working on an open source project is that every so often a community member you've never heard of will speak up and make a brilliant suggestion that even after years of devoted work on the project everyone else somehow missed. Exactly this happened last fall a few weeks before JXSE 2.4.1 went final and unfortunately too late for it to be included in JXSE 2.4.1 but it is now available in JXSE 2.5. The old jxta.org bugzilla was not preserved when we transfered the JXSE project to Java.net, so I have lost track of the name of the user who suggested the feature. If you're willing to step forward and identify yourself I'd be very happy to acknowledge your contribution.
<p/>The cool feature which is the subject of this blog is the <a href="http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider">JAR Service Provider</a>, otherwise known as the <tt>META-INF/services</tt> system. The <tt>META-INF/services</tt> system allows for the dynamic registration of instance classes for a particular interface. We are now using it for several of the JXSE class factories and the JXSE Class Loader.
<p/>To register classes you list the class names implementing an interface in a file named for the interface in the <tt>META-INF/services</tt> folder of your JAR file. For example, to register new Advertisement types you include a file "<tt>net.jxta.document.Advertisement</tt>" in the <tt>META-INF/services</tt> folder of your JAR containing the full names of your Advertisement classes. During startup the JXSE <tt>AdvertisementFactory</tt> will read class names from that file and register classes. The process is repeated for each <tt>net.jxta.document.Advertisement</tt> file in all of the other JARs.
<p/>Use of the <tt>META-INF/services</tt> system makes it much, much easier to extend JXSE by adding your own components. Adding support for your advertisement type to JXSE now requires only including the class names in the <tt>net.jxta.document.Advertisement</tt> file of your JAR file. You can also register <tt>StructuredDocument</tt> types, <tt>ID</tt> formats, <tt>WireMessageFormat</tt>s and JXTA Services and Modules. We have converted JXSE to use the <tt>META-INF/services</tt> system for all of the core modules. https://blogs.oracle.com/bondolo/entry/jxse_2_5_what_sJXSE 2.5 : What's Cool #1 -- NIO TCPmduigou 2007-09-05T14:44:13+00:002007-09-06T23:12:56+00:00<a href="https://jxta-jxse.dev.java.net">JXSE (JXTA for Java SE/EE 5.0)</a> 2.5 contains quite a number of exciting changes for JXTA application developers. This little series will look at a few of the important changes in the upcoming release.
<p/>JXSE provides two primary low-level message transports; TCP and HTTP. In the vast majority of cases, even for peers which are behind NAT and firewalls, the TCP message transport is used because it offers the best performance, lowest overhead and lowest latency. The HTTP message transport is used only when it not possible for a peer to open outbound TCP connections to other peers. Since the TCP message transport is so critical to JXSE we chose to focus on improving it for 2.5.
<p/>The refactoring of the TCP message transport was begun and has been spearheaded by <a href="http://blogs.sun.com/hamada">Mohamed Abdelaziz (hamada)</a>. He started the job by replacing all of the traditional <tt>java.net.Socket</tt> blocking I/O with a non-blocking <tt>java.nio.SocketChannel</tt> implementation. This initial work enabled us to start to look at the remaining bottlenecks, opportunities and challenges. A number of JXTA developers found hamada's contribution interesting and exciting. Even at this early point it managed to attract my attention as well as <a href="http://blogs.sun.com/slowhog">Henry Jen (slowhog)</a>, Roger Karis (malveaux) and others. slowhog contributed bug fixes and improvements based upon testing the code running on the JXTA public rendezvous servers. I contributed optimizations and a refactoring of the WireFormatMessageFactory and the binary message format to improve performance. malveaux, as usual, contributed his keen analysis and insight to help solve more than a few gnarly problems.
<p/>One of the new features and advantages of the new NIO based TCP message transport is much better use of Java Threads. We no longer require nearly as many threads per Socket instance and make extensive use of <tt>java.util.concurrent.Executor</tt> to effectively handle messages. As the new NIO based TCP message transport became more solid it became very clear that there were significant bottlenecks in how the JXSE Endpoint processed messages. The solution was to make even further use of <tt>Executor</tt>s and perform all message processing on <tt>Executor</tt>s. This surgery required enhancement of the HTTP message transport, the multicast message transport (which is now a separate message transport, but that's another story) and the relay. Again it was a good all around effort with contributions from hamada, slowhog, malveaux, myself and others. Mike Cumings (mcumings) contributed significant insights regarding best-practice use of <tt>Executors</tt>.
<p/>The result of all this work is that JXSE 2.5 makes considerably more efficient use of Threads while significantly improving throughput and latency. This is particularly important for infrastructure peers such as relays and rendezvous as it enables them to handle larger numbers of clients and much more load per instance. We're quite sure that JXTA network operators are going to appreciate this change.
<p/>For JXTA users and applications which are heavily dependant upon the HTTP message transport JXSE 2.5 does offer some improvement by using Executors for message processing, but we haven't yet transitioned the message transport to use NIO. Some early explorations have begin looking in to using the <a href="https://grizzly.dev.java.net/">Grizzly</a> HTTP server but we're still looking for contributors (especially those with Grizzly experience) to step forward and get something working. It also seems that some additional code sharing is possible between message transports by using the low-level Grizzly APIs. Contributors to investigate this opportunity are also eagerly sought!
<p/>The NIO based TCP message transport is a significant addition to JXSE 2.5 and probably provides the most dramatic change to the profile of JXTA applications of all the changes in JXSE 2.5. It is not a change though that's directly visible to applications in terms of new APIs or functionality. Future articles will look at some of the other changes in JXSE 2.5 and their benefits to JXTA application developers and users.https://blogs.oracle.com/bondolo/entry/pavlova_is_wrong_for_jxsePavlova is Wrong for JXSE 2.5mduigou 2007-09-04T20:22:54+00:002007-09-05T03:22:55+00:00A long time ago the name "Pavlova" was nominated as a JXSE (JXTA for Java SE/EE 5.0) release name. JXSE releases are named for celebratory foods and we have had releases named after foods from every continent and many cultures. <a href="http://en.wikipedia.org/wiki/Pavlova_%28food%29">Pavlova</a> is a light, fluffy, airy, subtle meringue dessert from New Zealand or Australia (depending on who you ask or trust). JXSE 2.5 is, to contrast, the most significant JXSE release since JXTA 2.0 four years ago. JXSE 2.5 is the result of ten months of intense development and testing by more than a dozen contributors. It offers significant improvements to the functionality, performance, scalability, maintainability, monitorability, reliability and several more "ability"s... Beyond JXSE itself we will also be releasing a new and significantly updated edition of the JXTA Programmers Guide. This is a going to be a major event for JXTA!
<p/>When we began the 2.5 release cycle we originally imagined that it would be a routine release with the normal mix of new features, improvements and bug fixes. Instead we are now completing a much more significant release. The key factor which catapulted the 2.5 release from a normal JXSE release to a jumbo sized release has been contributions from the JXTA community. In particular, the <a href="https://glassfish.dev.java.net/">Glassfish</a> <a href="https://shoal.dev.java.net/">Shoal</a> clustering project has been a big contributor to JXSE 2.5. Additionally, speaking of fish, the JXTA project's move to <a href="http://jxta.dev.java.net">Java.net</a> has moved us into a much bigger pond. It's been really exciting to see how many people are discovering JXTA as a result of this move.
<p/>At this point I don't think that the "Pavlova" name will be adequate JXSE 2.5 release. We would need a Guinness World Record sized Pavlova to suffice! I believe we need a name that truly reflects the scope, breadth and gut-busting hugeness of the JXSE 2.5 release. With a little searching I found <a href="http://en.wikipedia.org/wiki/Whole_stuffed_camel">Whole Stuffed Camel</a>, but since it can't be proved to have been actually prepared nor can I find a proper name for the dish I am ruling it out. Any other suggestions? The winning name must include a web accessible recipe for inclusion in the release notes. Bonus points if you can provide photos of having cooked the dish yourself!https://blogs.oracle.com/bondolo/entry/the_jxta_migrationThe JXTA Migrationmduigou 2007-06-20T11:33:13+00:002007-06-20T18:33:13+00:00For the last couple of weeks the JXTA project has gone through the difficult process of moving. Moving an open source project is, in most ways, easier than moving in the real world. For one thing, we haven't had to bribe our friends with beer and pizza in order to get them to help. Seriously though, it's been a significant amount of work for everyone involved to move all of the JXTA projects from <code>jxta.org</code> to <code>dev.java.net</code> and I believe that everyone has done a fantastic job.
<p/>Moving any web-site, particularly one with thousands of subscribers, is a tenuous business. The first fear is always "Will people follow?" and the related question "Will people be able to find the new site?" When your project has been running for a long time there are inevitably many links from all over the Internet. These links are incredibly valuable. They are how search engines such as Google decide that your site is worth indexing. Unfortunately, you won't be able to get everyone to update their links so there's more than a little anxiety while you wait for users and the search engines to find you again.
<p/>I personally believe it is important for the JXTA project to move forward boldly though. The Java.net community and site have a lot to offer for the JXTA project. We've already started to take advantage of some of the Java.net features that were unavailable to the JXTA.org site including discussion forums, subversion, greater control over style sheets, improved scalability, blogging, more RSS support, etc. There's probably a dozen more features we could use that I've not mentioned!
<p/>I'm very confident that moving to Java.net will be a good move for the JXTA community and for the JXTA technology. We've already had great interactions with other Java.net projects and the other Java.net community leaders (including their helping us steal and adapt their style sheets for the JXTA projects. Thanks <a href="https://shoal.dev.java.net">Shoal</a>!) I also believe that the current JXTA.org community will come to love our cozy new home.
<p/>The new home of JXTA on the web : <a href="https://jxta.dev.java.net">jxta.dev.java.net</a>https://blogs.oracle.com/bondolo/entry/more_discoveryDiscovery to Exhaustionmduigou 2007-05-06T18:02:00+00:002007-05-07T16:58:00+00:00More often than the seasons change someone will ask one of the following seemingly unrelated questions on the JXTA mailing lists or IRC :
<ul>
<li>I published an advertisement and my friend tried searching for it. He can't find my advertisement. Why?</li>
<li>How can I find the advertisements for all peers?</li>
<li>I searched for advertisements but always get the same ones. Why?</li>
<li>I searched for advertisements from two different peers using the same query but got different results . Why?</li>
</ul>
The answers to these questions can all be related back to the goal of JXTA Discovery--"Get me some advertisements which match this query". The fundamental purpose of JXTA Discovery is to solve only this single problem.
<p/>Ok, so that's what JXTA Discovery does. Sounds very reasonable. How does it impact the preceding question? The first thing to understand is that JXTA Discovery is incredibly lazy. Even lazier than your dead-beat brother-in-law. JXTA Discovery does only the absolute minimum amount of work needed to satisfy the goal "Get me some advertisements which match this query."
<p/>JXTA Discovery's laziness isn't actually laziness, it is efficiency (yes, I know, your brother-in-law says that too). By minimizing the amount of work done to satisfy each query JXTA Discovery limits the amount of networking resources consumed and the processing required by other peers. If all peers behave in a similar way, the result is that the network load for Discovery is minimized.
<p/>The key word in understanding how and when JXTA Discovery minimizes its effort in satisfying queries is "<i>some</i>". Saying that JXTA Discovery is only responsible for providing "<i>some</i>" results in response to queries provides JXTA Discovery with a lot of flexibility. JXTA Discovery never claims to offer the complete result to a query. It also never claims to offer a specific result to a query unless there is only a single result possible.
<p/>JXTA Discovery's goal of returning some advertisements for each query does imply a promise to return advertisements, if available, in response to all valid queries. JXTA Discovery tries hard to always return a result, if possible, for each query. Depending on how narrow or broad your query is the "quality" of the set of results will vary. The varying quality of the results can be related back to Discovery's efforts to minimize the work that it does. JXTA Discovery does allow you to issue unqualified queries for advertisements. These queries offer JXTA Discovery the broadest opportunity to be lazy and generally return the lowest quality and most incomplete results. Generally, if you find that the advertisements that JXTA Discovery is returning are not the ones you want or expect then you should be asking a different and more specific question.
<p/>Now with that background and context, how about some direct answers to the questions we began with:
<dl>
<dt><b>I published an advertisement and my friend tried searching for it. He can't find my advertisement. Why?</b></dt>
<dd>Your friend is probably not searching specifically for your advertisement but instead for all advertisements of the same type. You should not expect that JXTA Discovery will return a specific advertisement (your advertisement) in response to a generic request.</dd>
<dt><b>How can I find the advertisements for all peers?</b></dt>
<dd>You can't and shouldn't ever need to find all instances of any advertisement. JXTA Discovery does not promise to ever return exhaustive results in response to a query. If it is hard to understand why JXTA Discovery doesn't allow this, consider what would happen if there were 1 zillion peers on the network. The amount of effort required to respond to your query, assuming that your peer could even handle the response, would bring the network to it's knees. JXTA Discovery won't allow you to do this. Additionally, there are also issues related to the network's dynamic nature which make enumerating all of anything nearly impossible anyway.</dd>
<dt><b>I searched for advertisements but always get the same ones. Why?</b></dt>
<dd>JXTA Discovery is likely being lazy (efficient). Your query is probably generic enough that the results returned satisfy the "some results" requirement while allowing JXTA Discovery to do a minimal amount of work. This type of problem can usually be resolved by issuing a more specific Discovery query.</dd>
<dt><b>I searched for advertisements from two different peers using the same query but got different results . Why?</b></dt>
<dd>This question has the same answer as the previous question. In addition, you should not expect a specific result to any Discovery query unless the query has only one answer. In particular, it's likely that different peers will see different results to the same query.</dd>
</dl>
<p/>Summarizing the important ideas about JXTA Discovery that you should remember. <i>JXTA Discovery is not a database.</i> It does not provide exhaustive (complete) responses to queries though it will try to return some results if any exist. <i>JXTA Discovery is generally not deterministic.</i> You cannot depend upon JXTA Discovery to return a specific result to any query unless that query has only one answer.https://blogs.oracle.com/bondolo/entry/generic_adviceGeneric Advicemduigou 2007-05-02T16:42:53+00:002007-05-03T00:06:45+00:00So you think you know everything there is to know about Java generics, eh? Well, we could use some advice. In the JXTA JSE 2.5 release we have added significant usage of generics to the existing JXTA APIs. In most cases the additional clarity is extremely beneficial and makes using and understanding the APIs simpler.
<p/>We have, however, run into at least one gnarly issue with generics in JXTA's Document APIs. Our original generics implementation for the Document APIs was built as suggested by the NetBeans and IDEA IDEs. It had some weaknesses though, especially in the messiness around using Enumerations over elements.
<p/><table align="center" width="90%" bgcolor="F0F0F0">
<caption>
<b><tt>Illegal Enumeration Usage</tt></b>
</caption>
<tbody>
<tr><td>
<pre>
public void method(XMLElement foo) {
Enumeration&lt;XMLElement> bar = foo.getChildren();
while( bar.hasNextElement() ) {
XMLElement baz = bar.nextElement();
method(baz);
}
}</pre>
</td></tr>
</tbody>
</table>
<p/>The problem with this example is that <tt>foo.getChildren()</tt> returns <tt>Enumeration&lt;? extends Element></tt> and without casting that can't be assigned to the very pleasent <tt>Enumeration&lt;XMLElement></tt>. Casting, in addition to not being fun to type, is the evil we're trying to avoid by moving to use generics.
<p/>So, after reading a blog somewhere regarding some generics best practices I refactored the JXTA Document APIs a bit and came up with an alternative implementation. I've unfortunately lost the link to the original blog in the two months since I did the refactoring or I'd post it. I've also created an issue in the JXTA JSE Bugzilla, <a href="http://platform.jxta.org/issues/show_bug.cgi?id=1655">Issue #1655</a>, to discuss the alternatives. The issue includes a patch to the current <a href="http://platform.jxta.org/source/browse/platform/">JXTA JSE CVS</a> which presents my alternative second implementation.
<p/>If, after looking at both implementations, you have any advice (or better yet, a patch proposal) for improving the usage of generics in the JXTA JSE document APIs we would be very appreciative.https://blogs.oracle.com/bondolo/entry/i_like_jxtaI Like JXTA!mduigou 2007-04-25T15:52:14+00:002007-04-25T22:52:14+00:00I have been working on the JXTA project for more than six years now. Almost eight years if you add in the time spent on the precursor project. Whether it's six years or eight years, I have worked on JXTA longer than any other single project in my career. Given the rapid pace of change in the computer software industry to work on "one thing" for eight years is very much an anomaly. My own short attention span and conditioned fear response to becoming pigeon-holed should also have inclined me to have long since moved on to the "next big thing". So, why am I still working on JXTA?
<p/>Quite simply, I like JXTA! JXTA has consistently been the most interesting and rewarding project I have ever worked on. The coolness of working on JXTA, for me, has several dimensions.
<p/>First, and foremost, is that JXTA is an open source project. This has enabled me to interact with developers and users with a far wider variety of perspectives (and cool projects) than I believe I would have encountered working on a traditional closed source project. I also believe that the JXTA project's use of a BSD style license has been important to helping foster the JXTA community. Having no impediments on use of the JXTA spec, technology or source has attracted many users that I don't believe would have found JXTA as attractive under another license.
<p/>Another cool aspect of working on JXTA has been the technology itself. Building high performance, robust, efficient software for real-world hetrogenous networks is not trivial. JXTA solves, or attempts to solve, some really difficult networking problems and provides developers an interface for building sophisticated collaboration applications. Working on the gnarly problems that JXTA solves has been incredibly interesting and rewarding.
<p/>Working on JXTA also been very much a learning experience. We've not been afraid to try new approaches and push the boundaries of technology. Not everything we've tried in the last six years as part of JXTA has been a perfect success, but we've hopefully learned as much or more from the efforts which have failed or fallen short as those which succeeded. Back to the community aspect, there are many false paths which we were able to avoid by using the JXTA community's collective experience. There have been just as many good ideas from the community which have made JXTA better as there have been bad ideas avoided.
<p/>My JXTA colleagues and Sun management have also made JXTA a great project to work on. I keep saying that Sun is the last technology company I expect to ever work for. (Well, if you hang around me long enough you'll hear me say that). Sun has a fantastic work culture and I really, really love being able to tele-commute almost 100% of the time. Not having to commute lets me concentrate on what I like best, hacking code! The last couple of years haven't been the easiest time to work at Sun. I have to give Sun management a lot of credit for recognizing the value and potential of JXTA and continuing to fund development.
<p/>I'm not sure if I will still be working on JXTA in another six or eight years. If I could be assured that the next eight years would be as much fun as the last eight years I would be disappointed if I couldn't continue to work on JXTA!https://blogs.oracle.com/bondolo/entry/don_t_rely_on_remotepublishDon't Rely on remotePublish()mduigou 2007-04-20T16:13:16+00:002007-05-23T17:39:09+00:00Since it's earliest versions the JXTA JSE API has included <tt>remotePublish()</tt> as part of the Discovery API. This is unfortunate because <tt>remotePublish()</tt> is frequently misused and it's not really that useful to begin with. Some JXTA users assume that advertisements must be remote published to another peer in order for the advertisement to be discovered. <i><b>This is not true!</b></i> Unless the advertisement needs to discoverable while the peer is unreachable or offline then local publication is almost always sufficient. Part of the confusion is undoubtably due to the presence of two methods, <tt>publish()</tt> and <tt>remotePublish()</tt>. In the JXTA JSE and JXTA-C APIs <tt>remotePublish()</tt> and <tt>publish()</tt> are separate APIs for implementation efficiency reasons only. You should consider advertisement publication as only one concept--the <i>publish</i> operation with an option for <i>remote</i> republication. Remote publication is intended to be only a means for easily requesting remote republication. In every case where <tt>remotePublish()</tt> is used it should be accompanied by appropriate local publication.
<p/>What <tt>remotePublish()</tt> does : send the provided advertisement to remote peers who <i>may</i> republish the advertisement locally. There a couple of big question marks that should arise from this statement.
<ul>
<li>What is gained by having the other peers republish one of my advertisements?</li>
<li>Which other peers will be receiving the advertisement?</li>
<li>Will the peers which receive the advertisement accept my request and actually publish my advertisement?</li>
</ul>
Let's delve into these questions a little further.
<p/>Peers publish advertisements to allow other peers to discover their resources. Normally the advertisements published by a peer refer either directly or indirectly to that peer. Direct references to the publishing peer most commonly are it's PeerID but can also include the peer's name or other application specificidentifiers. Indirect references include the PipeIDs for pipes the peer is listening on or references to other advertisements that the peer has also published. Even more indirect references include descriptions of services that the publishing peer might be running.
<p/>For advertisements with direct references it is certainly best if the publishing peer itself is the responder when queries are made for the advertisement. Not only does this ensure that the querying peer receives the most recent version of the advertisement it also ensures that the querying peer receives only active advertisements. For queries which return multiple results having only the original publisher respond can also improve the relevance of responses since responses will be generated only by (and referring to) active peers.
<p/>For advertisements with indirect peer references it's less important that the originating peer be the peer that responds to queries for the advertisement, but the same advantages that apply for advertisements with direct references may still apply. This is particularly true for pipe advertisements. The peers which respond should be the peers which are listening on the pipe. In cases where the same advertisement applies to many peers, as is common for pipe advertisements, as long as one of the publishers responds then the query will be satisfied.
<p/>So what's gained by having your advertisement republished via <tt>remotePublish()</tt> by other peers and when is it useful? Remote republication does provide an additional (an usually unnecessary) source for your advertisement. It also may make your peer's advertisement available when your peer is not available. This may or may not be a benefit as it could result in other peers wasting time trying to contact your peer when it is unreachable.
<p/>Once you've decided that you want your advertisement republished by other peers you are still faced with two additional questions, "Which peers can I ask to republish my advertisement and will they do so?" There are no simple answers to these questions and the answers are not consistent. These questions are difficult to answer for many reasons not limited to; varying network topologies, varying network policies and peer autonomy. <tt>remotePublish()</tt> is a request you make to other peers on the network. There is no way to force the other peers to accept your request nor is there guarantee that any other peers are even listening.
<p/>In <tt>remotePublish()</tt>'s default form no particular peer is asked to perform the republication, any peer receiving the message is requested to republish the advertisement. Even when you designate a specific peer with <tt>remotePublish()</tt> it is not required to accept your advertisement. A peer may choose to ignore your request due to space limitations, a configured policy or any other reason and it will not inform your peer of it's refusal.
<p/>Assuming another peer does choose to accept your <tt>remotePublish()</tt> republication request the peer may not retain the advertisement for the entire time you requested. Peers often place tight limits on the total number of advertisements they are willing to republish or on the expiration time of advertisements received through <tt>remotePublish()</tt>.
<p/>You may be wondering if there is any special interaction between <tt>remotePublish()</tt> and the RendezVous service. While it is true that in most network configurations a RendezVous peer is likely to receive all <tt>remotePublish()</tt> requests from it's client peers, RendezVous server peers do not offer any special republication privileges to their clients. All of the preceding restrictions still apply. In particular, the restrictions on advertisement expiration were added to JXTA implementations specifically to prevent RendezVous server peers from being flooded with long-lived bogus advertisements.
<p/>Here's a test we've made since 2002: "Does your application still work without remote publication?" Since even before JXTA JSE 2.0 we've considered making remote publish a "NO-OP" for some configurations, particularly ad hoc and relayed configurations. In ad hoc the remote republications all end up as very noisy and generally pointless multicast traffic. For relayed configurations removing <tt>remotePublish()</tt> would slightly reduce relay load. Since <tt>remotePublish()</tt> is occasionally useful and can sometimes slightly improve performance by reducing the number of hops a query must travel we've so far left it enabled. A properly written JXTA application shouldn't notice any significant changes if <tt>remotePublish()</tt> does nothing and in virtually every case the most reliable JXTA applications perform exactly the same with or without <tt>remotePublish()</tt>.
<p/>Thanks to malveaux, DolF, HenrikGrosen and others for the excellent conversation, questions and insights (including this topic) over the last couple of weeks on the <a href="irc://irc.freenode.net/#jxta">#jxta</a> IRC channel.
<p/><b>Important Clarification :</b> Some readers interpreted this entry as saying that <tt>remotePublish()</tt> is going to be removed or it's behaviour changed. There are no plans to change the way that <tt>remotePublish()</tt> works or to remove it, but readers should be careful in how they use remote publish and what they expect from it.https://blogs.oracle.com/bondolo/entry/wireshark_with_updated_jxta_supportWireshark with Updated JXTA Supportmduigou 2007-03-01T12:52:46+00:002007-03-02T00:46:53+00:00A few days ago the <a href="http://www.wireshark.org">Wireshark</a> project accepted a patch providing updated support for JXTA. The patch improves upon Wireshark's already excellent JXTA support by adding support for <a href="http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.html#jbmv2">JXTA Binary Message Version 2</a> which is available in JXTA-C 2.5 as well as improved handling of <a href="http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.html#trans-ipt-tcpipwm">TCP/IP Welcome Messages</a> and UDP messages.
<p/>There have been some improvements to Wireshark's analysis tools and the XML dissector that the JXTA dissector doesn't yet take advantage of. Any volunteers?
<p/>The updated JXTA support is not yet available in a release version of Wireshar but you can try it out by building Wireshark yourself or waiting for the 0.99.6 release which should be out by the end of March 2007.https://blogs.oracle.com/bondolo/entry/no_jxta_hacking_project_thisNo JXTA Hacking Project this Weekendmduigou 2007-02-27T18:38:47+00:002007-02-28T02:38:47+00:00For those who have been waiting for bated breath (Anyone? Anyone? Bueller?) for news of my latest weekend JXTA Hacking Project I am afraid that this note will disappoint. Rather than hacking I opted to spend time reviewing and editing the upcoming edition of the <a href="http://guide.jxta.org">JXTA Java JSE Programmers Guide</a>. <a href="http://blogs.sun.com/hamada">Hamada</a> has been leading the release process for this new edition and has done the bulk of the new writing. (He lead the last edition as well). Producing technical tutorial documentation like this guide is incredibly taxing and demanding work. That the upcoming release will be the 4th edition does help a bit. We have a lot of good text that can be re-used and the document framework is pretty comfortable.
<p/>I had hoped to get through the first 6 chapters this weekend but ran out of steam by the time I was half way through chapter 3. Maybe trying to spend a whole weekend editing and writing (not my forte) was overly ambitious. I'm going to try doing my Programmers Guide work in smaller chunks.
<p/>Overall, I'm pretty impressed by the additions that the 4th edition will include. The new examples and new text should address the most common questions and frustrations encountered by new JXTA developers. I'm also really interested in hearing the feedback of readers on the new edition. I expect that more than a few not-so-new JXTA developers will probably take a glance at the new Guide and I am especially interested in their feedback.https://blogs.oracle.com/bondolo/entry/another_weekend_another_jxta_hacking1Another Weekend, Another JXTA Hacking Projectmduigou 2007-02-20T11:47:36+00:002007-02-20T19:47:37+00:00Most weekends I spend shopping for and cooking food. Cooking is my primary non-computer related hobby and I generally find it a great diversion and distraction from my "real job".
<p/>Lately though I have been cooking up something very different. I've been devoting my weekends to hacking on JXTA mini-projects. Previously I've written about my explorations into <a href="http://blogs.sun.com/bondolo/entry/upnp_serversocketfactory_for_jxta_jse">UPnP port forwarding</a>. This weekend I worked on a project for <a href="http://blogs.sun.com/roller/page/hamada">hamada</a>. For <a href="https://shoal.dev.java.net/">Shoal</a> he needs a new propagation message transport for long distance propagation. Regular multicast won't work because routers refuse to forward multicast messages even with TTL set appropriately.
<p/>The solution I'm proposing is a lightweight point to point "propagation" transport using UDP. I've named it "JBone" because it's similar in purpose and flavour to <a href="http://en.wikipedia.org/wiki/Mbone">MBone</a> even though the implementation isn't nearly as sophisticated. JBone isn't intended to replace Rendezvous propagation but it should help out deployers who need to deploy "ad-hoc" networks across sub-nets. Currently the transport requires direct configuration of the addresses to forward propagation messages. Perhaps it can be made more dynamic and perhaps a system for scoping control could be added.
<p/>There are some other long distance propagation alternatives that JXTA could use that are not currently being used. These include sending propagation messages via the unicast transports, TCP and HTTP. The JXTA TCP transport even includes a flag in it's welcome message which is intended to control propagation-over-unicast behaviour. I'm really curious as to the utility of each approach.
<p/>Doing propagation over unicast transports is different than what JBone is doing though because the unicast based propagation would require that the connections be already established. JBone will happily send messages to destinations with no existing connections. There's good reason to be concerned that with many destinations cross specified that JBone could cause a huge increase in network traffic. It should be fine for very small numbers (<10) of peers though. https://blogs.oracle.com/bondolo/entry/upnp_serversocketfactory_for_jxta_jseUPnP ServerSocketFactory for JXTA JSEmduigou 2007-02-10T21:54:43+00:002007-02-12T18:00:34+00:00A few days ago for unexplained reasons, I think it was because I had been looking at the JXTA JSE TCP Message Transport accept() loop, I decided it might be cool to see if I could take advantage of the UPnP dynamic port forwarding feature.
<p/>I started by doing some lunchtime reading but beyond hundreds of message board posts "How do I get UPnP forwarding working for &lt;insert file sharing application name here&gt; with my &lt;insert consumer router name and model here&gt; so I can steal more movies?" and the inscrutable (and obviously machine generated) UPnP device profile documents I hadn't found much good information. I knew of several other open source projects which included UPnP port forwarding as a feature and I resolved to investigate when I got time.
<p/>Fast forward to Friday evening. It was raining and the Chinese New Year Parade (Solano Avenue's first) and dinner I had planned on was canceled. So I started digging into source. Somehow I got distracted several times but settled on trying to implement based upon the "Legacy NAT Traversal" code I found in <a href="http://developer.apple.com/opensource/internet/bonjour.html">mDNSResponder</a> (otherwise known as Bonjour). I got the code up to the point where I needed an actual UPnP device in order to test what I had written but my wife was doing email and wasn't thrilled by the prospect of me hauling off the wireless router to the garage for "harmless tinkering".
<p/>Saturday morning as I watched cartoons, I had found what looked to be some better resources for UPnP including the very spiffy looking Super Bonbon Industries <a href="http://www.sbbi.net/site/upnp/index.html">UPNPLib</a> and a <a href="http://www.sbbi.net/site/upnp/license/upnp-lib.html">heck of a good license</a> too.
<p/>Saturday evening, it's still raining. My wife is intent on sitting by the fire and building a giant <a href="http://www.knex.com/">K'nex</a> rollercoaster that if full size nobody would be able to keep their lunch on (or possibly even survive). Now's my chance to steal off to the laboratory (garage) with the wireless router and perform some experiments! Within minutes I have port forwarding running within NetBeans using the sample code provided on the Super Bonbon web site.
<p/>Following warnings I had read about the general bugginess of UPnP support by routers I spent some time experimenting with mapping and unmapping, looking at what happens when I try to remap the same address that's already mapped, halt the program with active mappings, play around with timeouts, etc. It turns out that my NetGear router is better than most.
<p/>I decided to abandon my Friday night code in favour of something new based upon UPNPLib. Pretty quickly I was able to put together a <a href="http://java.sun.com./javase/6/docs/api/javax/net/ServerSocketFactory.html"><tt>ServerSocketFactory</tt></a> that I could get JXTA to use by specifying it as the factory to <a href="http://platform.jxta.org/nonav/java/impl/net/jxta/impl/endpoint/IPUtils.html#setServerSocketFactory(javax.net.ServerSocketFactory)">
<tt>net.jxta.impl.endpoint.IPUtils</tt></a>. I have not tested the factory with JXTA, but I have done some testing with a standalone program to ensure that the forwarding works properly. The hard part, in theory, is done.
<p/>So now that I have written the code some doubts remain. I am concerned with how best to integrate and configure this feature into JXTA. I also still have a lot of questions and uncertainty about the viability of the feature as discussed on P2PHackers <a href="http://zgp.org/pipermail/p2p-hackers/2006-April/003810.html">UPnP Realworld Stats</a> and the previously mentioned thousands of message threads seeking assistance. Adding UPnP port forwarding as a feature could be a support nightmare. I'm also wondering about Stuart Cheshire's Internet Draft for <a href="http://files.dns-sd.org/draft-cheshire-nat-pmp.txt">NAT Port Mapping Protocol (NAT-PMP)</a>. Maybe it will catch on, maybe it won't. I'm also concerned that adding UPNPLib might be seen as a hardship by some because it requires several additional support jars. I don't want to require yet more jars with JXTA. UPnPLib also doesn't appear to handle IP multi-homing. While it is true that most people who would need to use UPnP port forwarding have only one IP connection I'm not willing to force JXTA to use only one connection.
<p/>Lastly, I wonder if UPnP port forwarding is a feature that interests JXTA users and developers. Is anyone developing JXTA applications that will be deployed primarily on home networks where UPnP support is most commonly found. Would adding inbound connectivity for an additional 20% of end users (wild guess number) be useful? As I mentioned I suspect that enabling UPnP port forwarding might have end user support cost implications but I also think that it is likely to require a lot of testing and fine tuning to be realistically deployable. Some of this work has undoubtedly been done by the Super BonBon Industries developers.
<p/>In spite of my doubts, I sure did have fun researching and hacking out the code so it was ultimately worth doing.
<p/><table width="100%" bgcolor="F0F0F0">
<caption>
<b><tt>UPnPServerSocketFactory.java</tt></b>
</caption>
<tbody>
<tr><td>
<pre>
package upnptest;
import java.io.IOException;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.util.logging.Logger;
import javax.net.ServerSocketFactory;
import net.jxta.impl.endpoint.IPUtils;
import net.jxta.impl.util.TimeUtils;
import net.sbbi.upnp.impls.InternetGatewayDevice;
import net.sbbi.upnp.messages.UPNPResponseException;
/\*\*
\*
\* @author mike
\*/
public class UPnPServerSocketFactory extends ServerSocketFactory {
/\*\*
\* Logger
\*/
private static final Logger LOG = Logger.getLogger(UPnPServerSocketFactory.class.getName());
private final InetAddress ANYADDRESS;
private InternetGatewayDevice[] IGDs = null;
private InternetGatewayDevice currentIGD = null;
private long lastIGDQueryAt = 0;
/\*\* Creates a new instance of UPnPServerSocketFactory \*/
public UPnPServerSocketFactory( ) throws IOException {
// XXX 20070210 bondolo IPv4 specific.
ANYADDRESS = InetAddress.getByName("0.0.0.0");
if( null == getCurrentIGD() ) {
throw new IOException( "No suitable internet gateway devices found." );
}
}
/\*\*
\*
\*/
public InetAddress getExternalAddress() throws IOException {
InternetGatewayDevice useIGD = getCurrentIGD();
if( null == useIGD ) {
throw new IOException( "No suitable internet gateway devices found." );
}
try {
String response = useIGD.getExternalIPAddress();
InetAddress result = InetAddress.getByName( response );
return result;
} catch (UPNPResponseException ex) {
IOException rethrow = new IOException( "UPnP Operation Failed : " + ex.getMessage() );
rethrow.initCause(ex);
throw rethrow;
}
}
/\*\*
\* {@inheritDoc}
\*/
public ServerSocket createServerSocket(int port ) throws IOException {
return createServerSocket( port, 0, ANYADDRESS );
}
/\*\*
\* {@inheritDoc}
\*/
public ServerSocket createServerSocket(int port, int backlog ) throws IOException {
return createServerSocket( port, backlog, ANYADDRESS );
}
/\*\*
\* {@inheritDoc}
\*/
public synchronized ServerSocket createServerSocket(int port, int backlog, InetAddress ifAddress)
throws IOException {
InternetGatewayDevice useIGD = getCurrentIGD();
if( null == useIGD ) {
throw new IOException( "No suitable internet gateway devices found." );
}
// The local socket. This is what we will pass back and what the router will forward to.
ServerSocket localServerSocket = new ServerSocket( port, backlog, ifAddress );
if( ifAddress.equals(ANYADDRESS) ) {
// FIXME 20070210 bondolo This is totally wrong and entirely speculative.
// But it does work if you're not mulithomed.
ifAddress = InetAddress.getLocalHost();
}
try {
boolean mapped = useIGD.addPortMapping( "JXTA TCP ServerSocket",
null, localServerSocket.getLocalPort(),
localServerSocket.getLocalPort(), ifAddress.getHostAddress(),
0, "TCP" );
} catch (UPNPResponseException ex) {
IOException rethrow = new IOException( "UPnP Operation Failed : " + ex.getMessage() );
rethrow.initCause(ex);
throw rethrow;
} catch( IOException failed ) {
try {
localServerSocket.close();
} catch( IOException ignored ) {
;
}
throw failed;
}
return localServerSocket;
}
private synchronized InternetGatewayDevice getCurrentIGD() {
if( TimeUtils.toRelativeTimeMillis( TimeUtils.timeNow(), lastIGDQueryAt) > (5 \* TimeUtils.AMINUTE) ) {
IGDs = null;
currentIGD = null;
try {
IGDs = InternetGatewayDevice.getDevices( (int) (5 \* TimeUtils.ASECOND) );
if( null != IGDs ) {
// FIXME 20070210 bondolo This may cause us to change IGD even though
// our current one has not failed.
currentIGD = IGDs[0];
}
} catch( IOException failed ) {
}
lastIGDQueryAt = TimeUtils.timeNow();
}
return currentIGD;
}
}
</pre>
</td></tr>
</tbody>
</table>
https://blogs.oracle.com/bondolo/entry/log4j_to_java_util_loggingLog4J to java.util.logging -- Jackpot!mduigou 2007-01-31T09:32:44+00:002007-08-13T19:21:39+00:00A few days ago the JXTA JSE project announced that we had converted all of our logging code from using <a href="http://logging.apache.org/log4j/docs/">Apache Log4J</a> to using <tt>java.util.logging</tt>. With nearly 6000 logging statements in the core JXTA <a href="http://platform.jxta.org">platform</a> and many thousands more in the JXTA <a href="http://shell.jxta.org">Shell<a/>, <a href="http://cms.jxta.org">CMS</a>, and <a href="http://myjxta2.jxta.org">myJXTA2</a> the conversion process could have been a very daunting tasking. Luckily we had the perfect tool available, <a href="http://jackpot.netbeans.org">Jackpot</a>. Jackpot is a rule based Java source reengineering tool. It's not just a refactoring tool, it can do lots of other amazing source transformations using either code or text based rules. For a task of this nature and size, Jackpot was the perfect tool.
<p/>I recommend performing Jackpot conversions only on a copy of your workspace or a clean checkout from your version control system. If something goes wrong it can be very difficult (if not impossible) to revert the changes made by Jackpot.
<p/>The first step in our conversion is to normalize the usage of Log4J statements. There are a few differences between the Log4J and <tt>java.util.logging</tt> APIs that are difficult to convert directly. By normalizing all of the Log4J output statements to use either the form "<tt>&lt;<i>Logger</i>&gt;.log( &lt;<i>Level</i>&gt;, &lt;Message</i>&gt;)</tt>" or "<tt>&lt;<i>Logger</i>&gt;.log( &lt;<i>Level</i>&gt;, &lt;<i>Message</i>&gt;, &lt;<i>Throwable</i>&gt;)</tt>" the rest of the conversion goes more smoothly. We also convert a few convenience methods to their root form.
<p/><table width="100%" bgcolor="F0F0F0">
<caption>
<b>Log4J to java.util.logging Jackpot Rules : Normalization.rules</b>
</caption>
<tbody>
<tr><td>
<pre>
/\*\*
\* Convert Log4J to java.util.logging :: Normalize all of the logging statements.
\*/
$L.trace($m,$e) => $L.log( org.apache.log4j.Level.TRACE,$m,$e) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String && $e instanceof java.lang.Throwable;
$L.debug($m,$e) => $L.log( org.apache.log4j.Level.DEBUG,$m,$e) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String && $e instanceof java.lang.Throwable;
$L.info($m,$e) => $L.log( org.apache.log4j.Level.INFO,$m,$e) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String && $e instanceof java.lang.Throwable;
$L.warn($m,$e) => $L.log( org.apache.log4j.Level.WARN,$m,$e) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String && $e instanceof java.lang.Throwable;
$L.error($m,$e) => $L.log( org.apache.log4j.Level.ERROR,$m,$e) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String && $e instanceof java.lang.Throwable;
$L.fatal($m,$e) => $L.log( org.apache.log4j.Level.FATAL,$m,$e) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String && $e instanceof java.lang.Throwable;
$L.trace($m) => $L.log( org.apache.log4j.Level.TRACE,$m) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String;
$L.debug($m) => $L.log( org.apache.log4j.Level.DEBUG,$m) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String;
$L.info($m) => $L.log( org.apache.log4j.Level.INFO,$m) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String;
$L.warn($m) => $L.log( org.apache.log4j.Level.WARN,$m) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String;
$L.error($m) => $L.log( org.apache.log4j.Level.ERROR,$m) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String;
$L.fatal($m) => $L.log( org.apache.log4j.Level.FATAL,$m) ::
$L instanceof org.apache.log4j.Logger && $m instanceof java.lang.String;
$L.trace($e,$e) => $L.log( org.apache.log4j.Level.TRACE, $e.getMessage(), $e) ::
$L instanceof org.apache.log4j.Logger && $e instanceof java.lang.Throwable;
$L.debug($e,$e) => $L.log( org.apache.log4j.Level.DEBUG, $e.getMessage(), $e) ::
$L instanceof org.apache.log4j.Logger && $e instanceof java.lang.Throwable;
$L.info($e,$e) => $L.log( org.apache.log4j.Level.INFO, $e.getMessage(), $e) ::
$L instanceof org.apache.log4j.Logger && $e instanceof java.lang.Throwable;
$L.warn($e,$e) => $L.log( org.apache.log4j.Level.WARN, $e.getMessage(), $e) ::
$L instanceof org.apache.log4j.Logger && $e instanceof java.lang.Throwable;
$L.error($e,$e) => $L.log( org.apache.log4j.Level.ERROR, $e.getMessage(), $e) ::
$L instanceof org.apache.log4j.Logger && $e instanceof java.lang.Throwable;
$L.fatal($e,$e) => $L.log( org.apache.log4j.Level.FATAL, $e.getMessage(), $e) ::
$L instanceof org.apache.log4j.Logger && $e instanceof java.lang.Throwable;
$L.trace($m) => $L.log( org.apache.log4j.Level.TRACE,$m.toString()) :: $L instanceof org.apache.log4j.Logger;
$L.debug($m) => $L.log( org.apache.log4j.Level.DEBUG,$m.toString()) :: $L instanceof org.apache.log4j.Logger;
$L.info($m) => $L.log( org.apache.log4j.Level.INFO,$m.toString()) :: $L instanceof org.apache.log4j.Logger;
$L.warn($m) => $L.log( org.apache.log4j.Level.WARN,$m.toString()) :: $L instanceof org.apache.log4j.Logger;
$L.error($m) => $L.log( org.apache.log4j.Level.ERROR,$m.toString()) :: $L instanceof org.apache.log4j.Logger;
$L.fatal($m) => $L.log( org.apache.log4j.Level.FATAL,$m.toString()) :: $L instanceof org.apache.log4j.Logger;
$L.isDebugEnabled() => $L.isEnabledFor(org.apache.log4j.Level.DEBUG) :: $L instanceof org.apache.log4j.Logger;
$L.isInfoEnabled() => $L.isEnabledFor(org.apache.log4j.Level.INFO) :: $L instanceof org.apache.log4j.Logger;
$L.getLogger($C) => $L.getLogger($C.getName()) :: $L instanceof org.apache.log4j.Logger && $C instanceof java.lang.class;
</pre>
</td></tr>
</tbody>
</table>
<p/>The second step in the conversion is to actually convert from Log4 to <tt>java.util.logging</tt>. This step is the dangerous one because if any part of the conversion produces code which doesn't compile there is no easy way to revert the changes. (I had lots of fun debugging this step).
<p/><table width="100%" bgcolor="F0F0F0">
<caption>
<b>Log4J to java.util.logging Jackpot Rules : Conversion.rules</b>
</caption>
<tbody>
<tr><td>
<pre>
/\*\*
\* Convert Log4J to java.util.logging :: Convert from Log4J to java.util.logging
\*/
/\*
$L.isEnabledFor(Level.TRACE) => Logging.SHOW_FINER && $L.isLoggable(Level.FINER) :: $L instanceof org.apache.log4j.Logger;
$L.isEnabledFor(Level.DEBUG) => Logging.SHOW_FINE && $L.isLoggable(Level.FINE) :: $L instanceof org.apache.log4j.Logger;
$L.isEnabledFor(Level.INFO) => Logging.SHOW_INFO && $L.isLoggable(Level.INFO) :: $L instanceof org.apache.log4j.Logger;
$L.isEnabledFor(Level.WARN) => Logging.SHOW_WARNING && $L.isLoggable(Level.WARNING) :: $L instanceof org.apache.log4j.Logger;
$L.isEnabledFor(Level.ERROR) => Logging.SHOW_SEVERE && $L.isLoggable(Level.SEVERE) :: $L instanceof org.apache.log4j.Logger;
$L.isEnabledFor(Level.FATAL) => Logging.SHOW_SEVERE && $L.isLoggable(Level.SEVERE) :: $L instanceof org.apache.log4j.Logger;
\*/
org.apache.log4j.Level.TRACE => java.util.logging.Level.FINER;
org.apache.log4j.Level.DEBUG => java.util.logging.Level.FINE;
org.apache.log4j.Level.INFO => java.util.logging.Level.INFO;
org.apache.log4j.Level.WARN => java.util.logging.Level.WARNING;
org.apache.log4j.Level.ERROR => java.util.logging.Level.SEVERE;
org.apache.log4j.Level.FATAL => java.util.logging.Level.SEVERE;
$L.toLevel($s) => $L.parse($s) :: $L instanceof org.apache.log4j.Level && $s instanceof java.lang.String;
mapclass org.apache.log4j.Level => java.util.logging.Level;
mapclass org.apache.log4j.Logger => java.util.logging.Logger;
</pre>
</td></tr>
</tbody>
</table>
<p/>It should now be possible to remove Log4J from your classpath. The final step in the conversion is to reverse some of the API normalization we did in the first steps and make use of <tt>java.util.logging</tt> convenience methods.
<p/><table width="100%" bgcolor="F0F0F0">
<caption>
<b>Log4J to java.util.logging Jackpot Rules : Simplification.rules</b>
</caption>
<tbody>
<tr><td>
<pre>
/\*\*
\* Convert Log4J to java.util.logging :: Simplify.
\*/
$L.log(Level.FINER,$m) => $L.finer($m) :: $L instanceof java.util.logging.Logger && $m instanceof java.lang.String;
$L.log(Level.FINE,$m) => $L.fine($m) :: $L instanceof java.util.logging.Logger && $m instanceof java.lang.String;
$L.log(Level.INFO,$m) => $L.info($m) :: $L instanceof java.util.logging.Logger && $m instanceof java.lang.String;
$L.log(Level.CONFIG,$m) => $L.config($m) :: $L instanceof java.util.logging.Logger && $m instanceof java.lang.String;
$L.log(Level.WARNING,$m) => $L.warning($m) :: $L instanceof java.util.logging.Logger && $m instanceof java.lang.String;
$L.log(Level.SEVERE,$m) => $L.severe($m) :: $L instanceof java.util.logging.Logger && $m instanceof java.lang.String;
</pre>
</td></tr>
</tbody>
</table>
<p/>I would like to thank Tom Ball for assisting with the Jackpot scripts when we had problems with our initial conversion attempt back in June. Tom was very helpful in correcting our mistakes and adding additional flourishes that we likely wouldn't have figured out on our own. Jackpot is a very cool tool and was indispensable for this task. We expect that we will find many other uses for Jackpot within the JXTA project and will be keeping an eye out for other people's refactoring and reengineering scripts.
<p/>On the behalf of the JXTA community we would also like to thank the developers of Log4J and Chainsaw for their hard work and for producing such an excellent, well supported and well thought out product. Log4J has been a part of JXTA since early in 2001 and served us very well. I would also like to thank Nelson Minar for originally integrating Log4J into JXTA.
https://blogs.oracle.com/bondolo/entry/december_flurriesDecember Flurriesmduigou 2006-12-20T14:04:34+00:002006-12-20T22:04:34+00:00<p>The JXTA JSE project has had a lot of activity in the last couple of weeks. It's been quite a while since there have been this many commits in such a short period of time.<br /><br />Many of the commits have been the result of generics refactoring as suggested by either the NetBeans IDE or IDEA. We're hoping that adding generics specifications to the public JXTA APIs will reduce some of the &quot;but a Vector of what?!?&quot; frustrations. All of your existing code should compile without change with the new generics API improvements. If you do find errors it's probably something that was previously undiagnosed due to the lack of complete type information.<br /><br />It's also important to mention that the next JXTA release planned for early February will include the removal of quite a few deprecated methods. Most of these methods have been deprecated for at least a year and in most cases two years are more. All deprecated methods and classes should provide good javadoc comments instructing you how to adapt your code to avoid using the APIs which will be removed. If the documentation is in anyway insufficient please post your questions and/or create a bug and we will work to improve the documentation or provide alternatives.</p><p>Not all of the recent commits have been mere API cleanups. There have been a number of important improvements to the platform (such as the greatly simplfied Rendezvous Walker implementation) and there are several very exciting patches which are still being worked on.<br /><br />In particular the Pavlova release will include a new NIO based implementation of the JXTA TCP Message Transport. This will greatly reduce the thread consumption of rendezvous and relay peers and should provide considerable performance and throughput improvment for most operations. You can find out more by following <a href="http://platform.jxta.org/issues/show_bug.cgi?id=1583" target="_blank">Issue #1583</a>.<br /></p><p>We're also improving how rendezvous and relay seeding is done to reduce resource consumption and latency (the time it takes to get connected). The result is that not only do clients connect to their rendezvous and relay peers more quickly upon startup but they also don't make nearly as many connection attempts while starting up. The patch also includes some improvements to how peers get their seeding information and enhancements to the ACL feature for relay and rendezvous servers. You can find out more by following <a href="http://platform.jxta.org/issues/show_bug.cgi?id=1591" target="_blank">Issue #1591</a>.</p><p>But wait, there's more! The current CVS workspace was frozen for new features on December 19th. Only new features already marked for review will be accepted for the February 2007 release. Between now and the beta release the project focus will be to <a href="http://platform.jxta.org/issues/buglist.cgi?target_milestone=Pavlova&amp;keywords=Review" target="_blank">review proposed patches</a> (any community member may act as a reviewer, not just committers) and find and fix bugs. Consider trying your code against the <a href="http://download.jxta.org/build/nightly/" target="_blank">nightly builds</a> or wait for the beta release which should arrive around January 23rd, 2007.</p><p>&nbsp;The long term forcast? More flurries (of activity). </p>https://blogs.oracle.com/bondolo/entry/jxta_kitchen_invitationJXTA Kitchen Invitationmduigou 2006-10-24T15:06:35+00:002006-10-24T22:06:35+00:00On November 2nd and 3rd we will be holding the third annual JXTA Kitchen. This is an opportunity for JXTA application developers and deployers to get together with the core JXTA development team and do some deep dives into various aspects of the JXTA technology. Like past years the agenda is largely audience driven. Here's my blog entry from the first kitchen which might provide some context : <a href="http://blogs.sun.com/bondolo/entry/on_a_rainy_tuesday_in">First JXTA Kitchen</a>
<p/>The first day will be focused on the core team providing technology updates and discussing future directions. There will also be discussions of topics of interest to the participants. In the past these discussions have included tutorials, best practices, architectural reviews, gratuitous white-boarding and even some debugging.
<p/>The second day will be devoted to more specialized topics, small group discussions and architectural and code reviews of participant applications.
<p/>If you are interested in attending or have any questions about the event see : <a href="http://www.jxta.org/kitchen.htm">http://www.jxta.org/kitchen.htm</a> or contact <a href="mailto:marketing@jxta.org">marketing@jxta.org</a> for any questions. The event is free and "pay-your-own-way". Sun Microsystems will be providing the meeting space, wifi access and breakfast and lunch both days.https://blogs.oracle.com/bondolo/entry/building_and_testing_a_jxtaBuilding and Testing a JXTA Applicationmduigou 2006-07-17T19:59:43+00:002006-08-10T03:25:57+00:00Building and testing your first JXTA JSE application can be difficult. Here are some useful "tricks" which may help simplify the process.
<p/>If your application is planned to run on the whole internet then turn off TCP multicast while testing. Multicast provides different behaviours that are not available across the whole Internet. Your application may make incorrect assumptions which won't work once the application is deployed on the Internet. When you are satisfied that your application is working correctly you can turn on multicast as an optimization.
<p/>Use only one network transport. JXTA provides several network transports; TCP, HTTP and soon UDP and probably BlueTooth. Having traffic routed through multiple transports can be very confusing to debug and when things don't work it can be very difficult to figure out where the problem originates. Configure, tune and use only one network transport at a time until you are satisfied with how each performs. Once you have everything working you can enable multiple network transports as an optimization.
<p/>Don't run a rendezvous in the public network. If your peers are connected to the JXTA public network then you will not be able to run your own rendezvous. The public JXTA rendezvous servers use the ACL feature in order to exclude random "rogue" rendezvous to improve performance. This means that your rendezvous will not work correctly in the net peer group. There are two solutions you can use; isolate your peers on a disconnected network or use the JXTA private net peer group features.
<p/>Use JXTA Logging. If you are doing development with JXTA then you should enable WARN or INFO level logging. WARN or INFO log levels will provide you a lot of information about what JXTA is doing and how JXTA is configured. Enabling logging is perhaps the most important single way that you can reduce your frustration with debugging JXTA applications.
<p/>Use private networks. If your application will eventually need to use the JXTA private net peer group feature then you should enable this feature as soon as possible. Disconnecting yourself from the JXTA public network will remove a lot of the ambiguity and mystery because you will control all of the peers.https://blogs.oracle.com/bondolo/entry/thrice_is_that_even_aThrice? Is That Even a Word?mduigou 2006-06-21T15:56:53+00:002006-06-21T23:13:00+00:00Yesterday we announced the 14th quarterly release of JXTA JSE along with the 6th quarterly release of JXTA-C and 5th quarterly release of JXME. All arrived on schedule with the usual assortment of features and fixes. We have a pretty good track record going for delivering these releases. That must mean it's time to change things.
<p/>After much discussion amongst the release teams and with community members we are proposing to move to a "<a href="http://mathcentral.uregina.ca/QQ/database/QQ.09.03/graham1.html">Thrice yearly</a>" release schedule. We plan to continue to have regular releases around the beginnings of October, February and June.
<p/>There are several motivations for this change. Firstly, users and developers have told us that with the current high level of stability and maturity in the current JXTA releases they aren't strongly motivated to jump to new releases the moment they come out. There are some people who are interested in the absolute latest code, but they generally follow CVS or the nightly builds and don't pay attention to formal releases at all. For most JXTA users, adoption of new releases is tied to their own project schedules and plans or they are just learning about JXTA and it's not critical which release they use as long as it is similar to the most current release (should they decide to use JXTA in a project).
<p/>Secondly, we want to extend the development and testing phases of the release cycle. With a quarterly 13 week release schedule we have had 8 weeks of development and 5 weeks of "freeze". With the new "thrice yearly" 17 week release schedule we will have 11 weeks of development and 6 weeks of "freeze/testing". The extra time in each phase will hopefully allow more work to be committed. With the 13 week schedule we often found it was difficult to integrate larger changes and sometimes the process felt very rushed. Too often the "freeze/testing" period was shrunk as last minute features seemed to inevitably delay the code freeze. With the new schedule we are hoping to be more ruthless about enforcing the 6 week "freeze/testing" window and integrating the bigger patches earlier in the development cycle. We also believe that a longer development period will make it easier for community members to contribute code and features to JXTA as it is easier to make commitments based upon longer timelines.
<p/>Finally, going through a release cycle has a fairly high cost in time and attention for the developers and community. By moving to a "thrice yearly" (got that yet?) schedule we are hoping to have more time spent on features, testing, documentation and development. We're hoping that the result is there will be even more innovation and quality as part of each JXTA release.
<p/>The new release schedule is not official yet but we are expecting to set the dates of future JXTA releases very soon with the new schedule in mind. If you have feedback, comments, alternatives please share them now!https://blogs.oracle.com/bondolo/entry/what_comes_after_configurationWhat Comes after Configuration?mduigou 2006-06-19T09:20:42+00:002006-06-19T16:20:42+00:00The soon be released JXTA JSE 2.4 "Umqhusho" provides some exiting enhancements to one of JXTA's long term weak areas, configuration. Users and developers have been complaining for a long time that the process of determining and specifying configurations for JXTA peers is inflexible, complicated, inscrutable, inconvenient, buggy and probably a few more negative things. With the newest builds of JXTA this is hopefully changing.
<p/>We've been making steady progress for the last couple of releases to improve developers' initial experience with JXTA and fixing configuration is a big part of the changes. The JXTA 2.3.7 release saw important improvements to the <tt>ext.config</tt> JavaDocs, a few critical features such as private peer group support along with some critical bug fixes and some enhancements to how the home directory JXTA JSE uses is specified. The JXTA 2.4 release continues the progress with significant improvements to <tt>ext.config</tt>'s reliability, better default handling and improvements to the clarity of profiles.
<p/>The JXTA JSE 2.4 release introduces a new programmatic configuration class, <tt>NetworkConfigurator</tt>. This class provides a simplified, single class, programmatic configuration API. While <tt>NetworkConfigurator</tt> lacks some of the extensibility, functionality and features of <tt>ext.config</tt> it is probably a lot easier to understand for the new JXTA developer. <tt>NetworkConfigurator</tt> was originally developed as <tt>ConfigurationFactory</tt>, a utility for the JXTA sample programs so that users could run the tutorials out of the box. Users found it useful and told us that it fit their configuration needs. We would like to thank all of those who contributed code, reviews and feedback for this new feature.
<p/>We've also added two new classes which provide applications more flexibility and simpler control over how JXTA is started, <tt>WorldPeerGroupFactory</tt> and <tt>NetPeerGroupFactory</tt>. <tt>PeerGroupFactory</tt> is still available, though it is now deprecated. Over the next couple of months we will be updating the sample code, JXTA tutorials and Programmers Guide to use the new Peer Group constructors.
<p/>The title of this entry is meant to be a bit ironic. Too frequently we've heard that the problems that new users encountered with JXTA configuration and startup prevented them from ever getting fully exposed to JXTA. This has been a big disappointment, and it's something we have heard too many times. The good news is that hopefully our recent efforts at fixing the problem have begun to pay off. By a couple of measures the new user experience with JXTA is improving--the most obvious evidence is the questions being asked by users on the JXTA mailing lists. Configuration and initial setup issues have begun to diminish in proportion to questions about the core JXTA APIs. This is a good thing!
<p/>The second meaning of this entry's title is to discuss what's next. Firstly, everything is not "done" for improving the configuration and startup process. There have been recent discussions regarding how to abstractly configure JXTA services, some exciting work which performs JXTA configuration using Spring, and a great discussion regarding building a JXTA container which would run packaged &amp; configured JXTA based services. Secondly, I am hoping that for the next JXTA JSE release, scheduled for October 2006, that we will be able to improve the Peer Group creation and instantiation process, the <tt>PeerGroup.newGroup()</tt> methods. The primary goal is to provide a per-peer group configuration capability, but we are also looking to simplify and clarify the process of creating, publishing and instantiating peer groups. If you are interested in this topic consider getting involved by adding comments, issues and yourself as a cc: to <a href="http://platform.jxta.org/issues/show_bug.cgi?id=1545">Issue #1545</a>
<p/>So, what comes after configuration? Hopefully, lots of JXTA!