On Aug 7, 2008, at 9:22 AM, Chris Chen wrote:
> Quick question which I cannot find the answer to on the BAM page.
> How reliable is the BAM service? Does it provide a persistent
> subscription feature like JMS? In critical services where packets are
> sent and must be processed by a subscriber without losing that
> information, does BAM take care of this? Is there also a transaction
> feature to BAM where a message could either be put back into the queue
> to be retried if transaction fails and rolls back?
Not yet. The current queue capability is a simple memory-based
queue. Since we only added/cleaned-up the queue at the last minute,
there wasn't time to also add the persistent capabilities. It's
definitely in the plan. (I just added a bug report at
to make it concrete.)
The subscriber issue is interesting since Jabber defines persistence
as one of their "XEP" capabilities (XEP are mini-specs, basically
defining mixin capabilities.) I haven't quite figured out how to make
those capabilities work in a generic fashion, i.e. available for
anyone, not just tied to a specific chat implementation.
> it may be that BAM is currently geared towards the chat architecture
> such as twitter/IM/comet/etc so this may not apply, but I'd like to
> know the options available.
The persistence and XA does fit into the architecture. It's
interesting, as I work more with BAM examples, it's really more
capable than the lightweight IM/comet framework that we'd initially
envisioned. In the 3.2.1 timeframe, I'm planning on some ESB/SOA
experiments to see how well it works in that space.
> What's the plan for Resin's BAM and JMS implementation? Separate or
> may be integrated into one?
I'm going to try to integrate them. It'll be interesting, since BAM
is a slightly lower layer than JMS, since its payload is just a
Serializable and the only meta information are the "to" and "from".
So the JMS Message classes may define a JMS layer on top of BAM.
It'll take some experimentation to see how that will work.
A nice thing about developing in BAM is that it's so stripped-down,
that you can consider more use-case combinations than a more
complicated model like JMS.
> On Aug 7, 2008, at 8:58 AM, Scott Ferguson wrote:
>> Resin 3.2.0 is now available at the usual download http://caucho.com/download
>> . Release notes are at http://caucho.com/resin/changes/resin-3.2.0.xtp
>> Resin 3.2.x is the development branch. We have a full roadmap of
>> stuff to add to 3.2.x, so 3.2.x will be changing considerably for
>> release. For sites that don't want that kind of code-upheaval, use
>> the 3.1.x stable branch.
>> Much of the 3.2.0 work was underlying refactoring and distribution/
>> release refactoring. Jars have been merged, so resin.jar and
>> javaee-16.jar are the only needed jars for Resin OpenSource. Resin
>> Pro also needs pro.jar. Also, the resin.xml replaces resin.conf (to
>> make editors/mail happy), and a bunch of smaller changes in the
>> distribution layout.
>> The 3.2.0 release now includes a 32-bit debian package at the
>> site, which will make installation easier for Debian Linux sites
>> including Ubuntu.
>> For administration, the /resin-admin has been reworked and enhanced.
>> New capabilities include:
>> * graphing of critical statistics
>> * revised and enhanced summary page
>> * monitoring and display of slow requests
>> * new JMX page displaying all MBeans and attributes in the system
>> * revised web-app page including start/stop/restart
>> For alerts, we've added a "mail:" log-handler, which can email you a
>> compilation of the severe and critical log messages (this is very
>> The threading and socket management has been refactored to better
>> handle comet and jabber connections. During the checkout process, we
>> loaded it with 25,000 simultaneous comet connections as a stress
>> The distributed sessions have been reworked to use BAM as the
>> underlying transport, and the database restructured to handle planned
>> distributed object enhancements like distributed caching, and better
>> startup performance. Both the threading and session refactorings
>> major changes, so sites relying on them should do their own stress
>> Our JSF implementation now includes a handy debugging page, to better
>> show the state of the JSF system. The example at
>> shows this capability (see the bottom right corner.)
>> BAM (http://caucho.com/resin/doc/bam.xtp) has been refactored and
>> cleaned up. It can now act as a SEDA/queue replacement for memory-
>> based JMS queues. The client and service have been simplified, so
>> housekeeping overhead is now minimal. In addition, you can now
>> program to BAM using PHP, which is a very cool feature.
>> Share and Enjoy!
>> -- Scott
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list