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 http://bugs.caucho.com/view.php?id=2826 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 resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
