Re: [Resin-interest] Resin 3.2.0 is available
Great work! I will try to migrate my busy web app from 3.1.5.s080331 to 3.2.0. :-) - Original Message - From: Scott Ferguson [EMAIL PROTECTED] To: General Discussion for the Resin application server resin-interest@caucho.com Sent: Thursday, August 07, 2008 11:58 PM Subject: [Resin-interest] Resin 3.2.0 is available 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
Re: [Resin-interest] Resin 3.2.0 is available
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? 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. What's the plan for Resin's BAM and JMS implementation? Separate or may be integrated into one? -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
Re: [Resin-interest] Resin 3.2.0 is available
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
Re: [Resin-interest] Resin 3.2.0 is available
On Aug 7, 2008, at 9:56 AM, Scott Ferguson wrote: 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. I wrote an open source jabber client library before so JEP/XEPs are quite familiar to me. :) I don't have a fully concrete idea either but there are two sides to this subscription feature - client and server. The server side may be similar to how JMS EJB beans or Jabber Server side components work. The EJB side has a defined set of beans listening to a particular topic/queue. This is considered a subscription. As for persistent subscriptions, it can be similar to how JMS works as well. A client registers as a subscriber for a particular topic. Unless the client unsubscribes, the system will continue to store messages for this subscriber when the subscriber is offline. Of course, this comes with its own set of challenges. Fiorano MQ and ESB has a setting to periodically flush out any persistent messages. XMPP by nature has persistence message supported in some sense (ie. I get chat messages that were sent when I wasn't logged on). I wonder if a Jini-like persistence capability may be something to model after or even relevant in this case. Either way, persistent and subscription do go hand in hand. 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. I think integration is interesting, but more relevant are the use cases surrounding each type of system. *) BAM - lightweight for super fast and scalable message brokering for things such as stock market price streaming (no need for persistence) or twittering type messages. The main thing here is as fast as computerly possible. *) JMS/persistent subscriptions - These are for those that broker highly mission-critical data. The primary interest here is as reliable as possible. Speed is less of a concern compared to the data. Inherently, this type of use conflicts with BAM. Transactions will bog down the speed. *) ESB/SOA activities - these, in my view, are for those that require high data/service compatibility and integration. The message here is as promiscuous as possible. The focus is on the adapters and being able to communicate and connect to many different systems. I think all of them centers around a hub-spoke model. It's possible to integrate all of them together through layers. The lowest layer (in this case, BAM) focuses entirely on speed. A secondary layer can add the reliability that can be similar to XEP persistence. Possibly a persistence component that subscribes and listens to any topic/queue that requires such a service and separately deals with reliability. A third component can create a set of adapters to connect to different systems. This third component mainly focuses on data/message translation. Breaking the system up in these parts seems
