> From: Danny Angus wrote: <much snipped> > Anyway lets carry on turning over rocks and see what crawls out
Once we start distributing function across JVMs we have to be real smart to avoid a performance impact regardless of the protocol used. We also have to take care that the changes do not adversely impact non-distributed deployments.[1] Distribution invariably incurs the cost of serializing/deserializing to/from the transport. The trick is to transport the minimum necessary. In my experience, though the performance of particular implementations of JMS varies enormously, the dominant variant is the size of the objects transported. Another thing to remember is that JMS is just an interface specification. You can plug-in different implementations, but don't expect those implementations to talk to one and other without a JMS<>JMS bridge. That said, if we decide that distributed asynchronous processing is the way to go, I can see no rationale for cooking our own interface and implementation. I work in environments that support JMS transaction rates way above those typical of James, albeit with bigger hardware budgets. JMS also offers the opportunity of load-balancing by having several message consumers, offering the potential to increase the scalability of James. To me this is highly attractive. As Danny says, just "turning over rocks". -- Steve [1] In house we use a null JMS implementation wherein nothing ever gets serialized for local deployments. - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
