Wednesday Nov 07, 2007

JXTA JXSE 2.5 Released!

At 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!

Sunday Oct 14, 2007

JXSE 2.5 : What's Cool #7 -- Logging

JXSE (JXTA for Java SE/EE 5.0) 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.

One of the first major changes to occur in the JXSE 2.5 development cycle was our transition from Log4J to java.util.logging. I previously blogged here how we used Jackpot to do the conversion between the two APIs. The instigator of our transition to use java.util.logging was the Shoal project. Since all of Glassfish already used java.util.logging 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 java.util.logging first appeared in JDK 1.4. We've planned on changing to java.util.logging "eventually" for quite a while. The gentle nudge, and the offer of testing assistance from the Shoal, finally made doing the conversion a priority.

Following the conversion to java.util.logging the JXSE community has struggled a bit with the transition. The control mechanisms for java.util.logging 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 java.util.logging.

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.

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 java.util.logging it is now possible to selectively disable logging. The instructions are available as part of the JXSE 2.5 Javadoc (Which will be here once the page is updated for JXSE 2.5).

Tuesday Oct 09, 2007

JXSE 2.5 : What's Cool #6 -- PeerGroup Executor and ScheduledExecutor

JXSE (JXTA for Java SE/EE 5.0) 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.

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 java.util.concurrent utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.

The concurrency utilities provide several flavours of task executors. The Executor and ScheduledExecutor classes provide a convenient way to execute tasks without the overhead of the normal Thread lifecycle. For JXSE the use of Executor 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 Timer for periodic maintenance tasks. We expect that in future JXSE releases we will replace all of the Timer usage with ScheudledExecutor.

One difficulty we have found with Executor 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.

The Executor 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!

Thursday Oct 04, 2007

Wireshark JXTA Support Updated

A 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.

Thursday Sep 20, 2007

JXSE 2.5 : What's Cool #5 -- java.util.concurrent

JXSE (JXTA for Java SE/EE 5.0) 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.

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 java.util.concurrent utilities. In JXSE 2.5 we have continued to make much greater use throughout the JXSE source.

The use of the java.util.concurrent package, also known as the JSR-166 utilities, within JXSE 2.5 has been primarily about simplifying the implementation, obsoleting use of JXSE private utilities (mostly net.jxta.impl.util.UnbiasedQueue) 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 ConcurrentHashMap has been particularly useful in simplifying several areas which where very complicated due to concurrency requirements.

We have also found the java.util.concurrent.atomic utilities very useful for simplifying code which required atomic counters and atomic booleans. In a few places we have started to use the java.util.concurrent.locks utilities and expect that future versions of JXSE will make more use of these utilities.

The next entry in this series will talk about JXSE 2.5's use of the java.util.concurrent Executor and ScheduledExecutor.

About

mduigou

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today