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.

-- Scott

> -Chris
> 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  
>> each
>> 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  
>> download
>> 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
>> handy.)
>> 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  
>> test.
>> 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  
>> are
>> major changes, so sites relying on them should do their own stress
>> testing.
>> Our JSF implementation now includes a handy debugging page, to better
>> show the state of the JSF system.  The example at 
>> http://caucho.com/resin/examples/jsf-webbeans.xtp
>> 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  
>> the
>> 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@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

resin-interest mailing list

Reply via email to