0 Replies Latest reply on May 30, 2011 1:43 PM by stupormundi

    EJB3s in JBoss cluster affected by clustered messaging setup

    stupormundi Newbie

      Hi Group!


      I'm struggling with messaging setup for an (existing) JBoss cluster.


      Our project has, so far without problems, been using various EJB3s on a cluster.


      So far, our project hadn't used messaging, and the datasource defined in the /server/all/deploy/ as DefaultDS was HSQLDB (hsqldb-ds.xml).


      After experimenting with messaging / datasource setup a bit I've now set up a new postgres datasource used for messaging alone, called it "MessagingDS", leaving in place the existing "DefaultDS", and have configured the default queues (DLQ etc.) as clustered, configured some additional clustered queues, and set up a clustered PostOffice.


      I've added the additional attributes (for clustering) for DataChannelConfig and ControlChannelConfig into

      /server/all/deploy/messaging/postgresql-persistence-service.xml , as described in the messaging / clustering docs.


      Now, the clustered messaging works fine, BUT, those of our EJBs annotated like this:




      (to ensure a true Singleton on the cluster)


      ... have stopped working. More specifically, they now fail when they (or rather, a stateless ejb invoked by them) try to access data on hibernate, like so:


      javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.type.SerializationException: could not deserialize

              at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:77)

              at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)

              at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)

              at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

              at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)

              at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

              at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)

              at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)


      Caused by: javax.persistence.PersistenceException: org.hibernate.type.SerializationException: could not deserialize

              at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)

              at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:202)

              at org.jboss.jpa.tx.TransactionScopedEntityManager.find(TransactionScopedEntityManager.java:176)

              at org.example.myproj.SingletonServices.ejb3.MyStateLessBean.doHibernateStuff(MyStateLessBean.java:42)


      They used to work just fine before. Evidently, my additional setup for clustered messaging has screwed things up for those EJBs, but I don't understand how since I've left the DefaultDS as it was configured before.


      Any Ideas?


      ----------------------- UPDATE ! -------------------------


      More testing showed : my initial conclusion that only the HASingletonDeployer type Barrier EJBs are failing in their hibernate interactionns was wrong.


      I've now managed to invoke webservices that act on entity beans on both machines, and the entity beans on the machine that came up SECOND (that joined the cluster) always fail in their hibernate actions with "could not deserialize".


      I still have no idea what causes this. Since some jgroups configuration was part of setting up the clustered postoffice, could that config be interfering with the functioning of jgroups that underpins jboss cache?


      ... such as the mbean config of channels "DataChannelConfig" and "ControlChannelConfig" which I had to copy into postgresql-persistence-service.xml according to the 1.4.3 messaging docs for cluster setup...