JMS/clustering design and configuration question

Question

Hi:
          Any help or feedback much appreciated cos' this topic (no pun intended)
          seems to be complicated.
          I have an application that uses stateless session beans for mainline
          business functionality (heavy database writing) that is say then
          audited. The auditing is taken care of asynchronously by the SS bean's
          business method (after completing whatever it is doing) using a JMS
          connection factory to write to a queue which is consumed by a MDB. So,
          control is returned to the user ostensibly before the auditing is done
          for performance reasons. No transactional semantics are expected between
          the mainline business logic and the audit of same. So, our main use of
          JMS/MDB is for asynchrous operation. This design seems to be fine on a
          single server as long as a persistent store is configured.
          Now the hard part. We need to cluster - again for load-balancing and
          performance. As I've read thru this newsgroup and experimented some,
          I've quickly realized that it's not as simple as just configuring a
          cluster of just EJBs.
          Since the queues are basically used for asynch processing, would the
          following work?
          1) Set up a JMS server config for each WL server in the cluster targeted
          only for each WL server
          2) Set up a different queue for each JMS server with prefixed JNDI name
          (myserver1_someJNDIname)
          3) Configure/code the producer SS EJBs so that they ask the connection
          factory for a connection with a prefixed JNDI name (e.g
          myserver1_someJNDIname) based on the server they are running on (known
          perhaps from a property file local to each server)
          4) Target MDBs to be deployed on all servers in the cluster just like
          regular EJBs
          5) Finally, deploy the MDBs unjarred on each WL server and edit the
          weblogic-ejb-jar.xml on each server to set the -destination name-
          prefixed by the server on which it is deployed (e.g.
          myserver1_someJNDIname)
          Will the above basically accomplish what I'm after, which is a cluster
          of machines each equally capable of locally offloading asynchronous
          processing? I understand that for the most part WL server will use local
          EJBs, etc if they are available. I'm not particularly interested in
          failover at either EJB or JMS level, but rather HttpSession level so
          that if a WL server goes down another could pick up perhaps by by the
          user re-requesting whatever operation failed.
          If this is not possible because of the way clustering works (homogenous)
          then is there some other way to solve this problem. I basically do not
          want a cluster where there is a single point of failure (other than DB
          server) for any given piece of functionality.
          Thanks for any help.
          Alex
          

Answer 1

First and easiest,
          Just create a set of JMS tables for each server in your db. You can specify
          a JMS tablename prefix in your weblogic properties for eash server using
          weblogic.jms.tableNamePrefix=W5
          as long as the prefix is only two chars. This worked great for us until we
          decided to drop JMS because of its memory leaks. We were having to restart
          our servers every 8 hours.
          Second, get rid of JMS. Dirty little secret:You don't need JMS to do
          asynchronous work! You can use threads inside of J2EE and not break J2EE.
          Can't tell you how for proprietary reasons but you can.
          Mica Cooper