JBossDeveloper

Ovidiuf,

Thank you for the good documentation and the new version of the serverless JMS. I am anxious to work with this new code base this week.

If I may inquire, I'd like to know if you would be willing to receive code contributions? We can talk about this offline if that's appropriate?

It seems that you and Bela are the only ones working on this and my development team may be interested in helping out and expediting some features. We already developed our own pluggable protocol (Unicast, Multicast, etc...) with a free CORBA implementation. However, J2EE seems to have many features we'd like to exploit and it seems like a superior option if we can get some of the JMS features implemented that are show stoppers for our project.

So some of the things we'd like to have is the JNDI linked into JBoss NS (we'd like to have the ability to federate name services), getting the persistence and fault tolerance, message selectors (a must have for us), and possibly others I'm not thinking of right now - I may come across others as I prototype some things this week.

We'd like to get this up to a stable 1.0 release in the near future if that's possible and I'd like to talk more about it if you're interested?

You can reach me via email at: shark@ll.mit.edu


-Greg

It appears one can't send objects over the sljms implementation. Are there plans to add this soon? I only see text messages right now. Is this something trivial to implement?

I implemented the ObjectMessage (simple enough) just so I could run some tests. Is it possible to change the protocol stack for optimization and do the minimal configuration to increase performance? Every time I take out a protol on the stack it seems to complain. The JGroups documentation wasn't detailed enough for me to understand how to change around the protocol stack.

Also, can you explain the difference between the sljms.xml and the fc-fast.xml protocol stack files? How are each of these used?

Does the consumer or producer create the channel or whoever is started first?

Thanks.

I guess another way of posing my question would be. If I didn't care about reliability and only about performance, how would I configure these protocol stacks with the optimal configuration? What is the bare bones required?

If describing my data may help with optimizing the protocol stack...

I'm primarily sending radar state information. Just for a rough estimate, I serialized the objects to a file (I know this isn't the most accurate way of getting the true size of the objects) but they range from 1.3kb - 2.0kb serialized.

I was pretty happy with the rates I was sending out the text messages (I was able to get ~800 messages/second). Sending these objects I've been getting significantly less performance at ~100 messages/second and if I add more subscribers performance seems to degrade.

Perhaps if Bela could elucicate how I may optimize my protocol configuration for this type of data distribution?

Thanks.

I have not bridged between protocol stacks yet. I was planning on doing so for firewall traversal but haven't reached that point yet. I'd like to get some good numbers with the closest thing to pure multicast right now and then move from there.

Use the fc-fast protocol; I tested this on my home system, and got about 1600 msgs/sec.
fc-fast uses flow control, so it is very good when having *sustained* load over an extended period of time. But I'm sure you could optimize even more if you know the type of app (which you do).

Bela

I tried the bare-bones.xml file for jgroups - it doesn't work for sljms. I get the following:

[java] WARN 10:18:16,964 [main] (Trace.java:387) - fetching state will fail as state transfer is not supported. Add one of the STATE_TRANSFER protocols to your protocol specification

Use the fc-fast protocol; I tested this on my home system, and got about 1600 msgs/sec.
fc-fast uses flow control, so it is very good when having *sustained* load over an extended period of time. But I'm sure you could optimize even more if you know the type of app (which you do).