Saving a JMS Message in a Persistent Store

Hello Friends,
I am going to store a JMS message in a persistent store like a database and then recreate it when needed. What I will be doing is storing the JMS headers individually. Then storing all the properties and then the message body. I just wanted to confirm that with this data I would be able to recreate the entire message.

Not sure of the answer to this (I suspect re-creating the message with exactly the same values as it started with will be a bit more tricky than you would imaging). Why don't you try creating a blank message and setting every single header / property? You'll probably get some exceptions / values being over written when you send.
The real question is are you 100% sure you need to do this? The whole idea smells fishy. Why do you need the JMS Headers? Things would be far easier if the body of the message contained everything you needed. Why do you have to store the message in a database rather than leave it on a persistent queue?

Similar Messages

JMS Server and MySQL Persistent Store

          I set up a JDBC connection pool in Weblogic 8.1 with MySQL dbms. When I tried to
          create a JMS server and use the connection pool as the Persistent Store, then
          try to target the JMS to a managed server. I got the following error, any idea
          what the problem is?
          weblogic.management.DistributedManagementException: Distributed Management [1
          exceptions]
          JMS JDBC store, connection pool = , prefix = : unsupported DBMS
               at weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(ConfigurationMBeanImpl.java:1133)
               at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:462)
               at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
               at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
               at weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:765)
               at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
               at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
               at weblogic.management.configuration.ServerMBean_Stub.addDeployment(ServerMBean_Stub.java:7929)
               at weblogic.management.internal.DynamicMBeanImpl.unprotectedUpdateDeployments(DynamicMBeanImpl.java:1795)
               at weblogic.management.internal.DynamicMBeanImpl.access$100(DynamicMBeanImpl.java:95)
               at weblogic.management.internal.DynamicMBeanImpl$2.run(DynamicMBeanImpl.java:1708)
               at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
               at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
               at weblogic.management.internal.DynamicMBeanImpl.updateDeployments(DynamicMBeanImpl.java:1704)
               at weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:1128)
               at weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:311)
               at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1358)
               at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1333)
               at weblogic.management.internal.RemoteMBeanServerImpl.setAttribute(RemoteMBeanServerImpl.java:367)
               at weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:741)
               at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:475)
               at weblogic.management.configuration.JMSServerMBean_Stub.setTargets(JMSServerMBean_Stub.java:1247)
               at weblogic.management.console.webapp._domain.__jmsserver$ServerAndMigratableTargetAttribute.doSet(__jmsserver.java:109)
               at weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:256)
               at weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:173)
               at weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
               at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
               at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
               at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
               at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
               at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
               at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
               at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          java.io.IOException: JMS JDBC store, connection pool = , prefix = : unsupported
          DBMS
               at weblogic.jms.store.JDBCIOStream.throwIOException(JDBCIOStream.java:359)
               at weblogic.jms.store.JDBCIOStream.rebuildTables(JDBCIOStream.java:1613)
               at weblogic.jms.store.JDBCIOStream.open(JDBCIOStream.java:426)
               at weblogic.jms.store.JMSStore.open(JMSStore.java:224)
               at weblogic.jms.backend.BEStore.open(BEStore.java:262)
               at weblogic.jms.backend.BEStore.start(BEStore.java:151)
               at weblogic.jms.backend.BackEnd.openStores(BackEnd.java:1171)
               at weblogic.jms.backend.BackEnd.resume(BackEnd.java:1287)
               at weblogic.jms.JMSService.addJMSServer(JMSService.java:2167)
               at weblogic.jms.JMSService.addDeployment(JMSService.java:1938)
               at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:330)
               at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:201)
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
               at java.lang.reflect.Method.invoke(Method.java:324)
               at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:747)
               at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:726)
               at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:458)
               at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
               at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
               at weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:765)
               at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(Unknown Source)
               at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:466)
               at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:409)
               at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
               at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
               at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:404)
               at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          --------------- nested within: ------------------
          weblogic.management.console.utils.SetException: An error occurred while updating
          MigratableTarget on [Caching Stub]Proxy for dotnet:Name=CSJMSServer,Type=JMSServer
          - with nested exception:
          [weblogic.management.DistributedManagementException: Distributed Management [1
          exceptions]
          JMS JDBC store, connection pool = , prefix = : unsupported DBMS]
               at weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:311)
               at weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:173)
               at weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
               at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
               at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
               at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
               at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
               at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
               at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
               at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          Console Release Build8.1.1.0Server Release Build8.1.1.0Server BuildWebLogic Server
          8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 All Server Product VersionsWebLogic
          Server 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 WebLogic XMLX Module 8.1 SP1
          Fri Jun 20 23:06:40 PDT 2003 271009 WebLogic Server 8.1 SP1 Fri Jun 20 23:06:40
          PDT 2003 271009 WebLogic Server 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 WebLogic
          Portal 8.1 Thu Jul 10 20:09:22 PDT 2003 84868


Exactly what it says: unsupported DBMS.
          But but but...
          OK, I'll be nice (just couldn't resist).
          The next 8.1 SP will contain the DDL for MySQL, but for
          now you can run it manually. Prepend your catalog,
          schema, and prefix before JMSState and JMSStore to
          match what you configured as a prefix in your
          JMS JDBC store, and run the commands:
          CREATE TABLE JMSState (recordHandle int, recordState int,
          recordGeneration int);
          CREATE TABLE JMSStore (recordHandle int, recordState int, record longblob);
          CREATE INDEX JMSMSG_X ON JMSState (recordHandle);
          CREATE INDEX JMSMSGQ_X ON JMSStore (recordHandle);
          COMMIT;
          Note that a file store may be preferable instead
          of using a database store, there is
          likely no performance advantage to MySQL (in fact
          there is likely a significant performance penalty), and a file
          store is just as transactionally safe as a database
          store.
          Tom
          dahan wrote:
          > I set up a JDBC connection pool in Weblogic 8.1 with MySQL dbms. When I tried to
          > create a JMS server and use the connection pool as the Persistent Store, then
          > try to target the JMS to a managed server. I got the following error, any idea
          > what the problem is?
          >
          > weblogic.management.DistributedManagementException: Distributed Management [1
          > exceptions]
          > JMS JDBC store, connection pool = , prefix = : unsupported DBMS
          >      at weblogic.management.internal.ConfigurationMBeanImpl.updateConfigMBeans(ConfigurationMBeanImpl.java:1133)
          >      at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:462)
          >      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
          >      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
          >      at weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:765)
          >      at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
          >      at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
          >      at weblogic.management.configuration.ServerMBean_Stub.addDeployment(ServerMBean_Stub.java:7929)
          >      at weblogic.management.internal.DynamicMBeanImpl.unprotectedUpdateDeployments(DynamicMBeanImpl.java:1795)
          >      at weblogic.management.internal.DynamicMBeanImpl.access$100(DynamicMBeanImpl.java:95)
          >      at weblogic.management.internal.DynamicMBeanImpl$2.run(DynamicMBeanImpl.java:1708)
          >      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
          >      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
          >      at weblogic.management.internal.DynamicMBeanImpl.updateDeployments(DynamicMBeanImpl.java:1704)
          >      at weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:1128)
          >      at weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:311)
          >      at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1358)
          >      at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1333)
          >      at weblogic.management.internal.RemoteMBeanServerImpl.setAttribute(RemoteMBeanServerImpl.java:367)
          >      at weblogic.management.internal.MBeanProxy.setAttribute(MBeanProxy.java:741)
          >      at weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:475)
          >      at weblogic.management.configuration.JMSServerMBean_Stub.setTargets(JMSServerMBean_Stub.java:1247)
          >      at weblogic.management.console.webapp._domain.__jmsserver$ServerAndMigratableTargetAttribute.doSet(__jmsserver.java:109)
          >      at weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:256)
          >      at weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:173)
          >      at weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
          >      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >      at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
          >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
          >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
          >      at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
          >      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
          >      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
          >      at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
          >      at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
          >      at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
          >      at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          > java.io.IOException: JMS JDBC store, connection pool = , prefix = : unsupported
          > DBMS
          >      at weblogic.jms.store.JDBCIOStream.throwIOException(JDBCIOStream.java:359)
          >      at weblogic.jms.store.JDBCIOStream.rebuildTables(JDBCIOStream.java:1613)
          >      at weblogic.jms.store.JDBCIOStream.open(JDBCIOStream.java:426)
          >      at weblogic.jms.store.JMSStore.open(JMSStore.java:224)
          >      at weblogic.jms.backend.BEStore.open(BEStore.java:262)
          >      at weblogic.jms.backend.BEStore.start(BEStore.java:151)
          >      at weblogic.jms.backend.BackEnd.openStores(BackEnd.java:1171)
          >      at weblogic.jms.backend.BackEnd.resume(BackEnd.java:1287)
          >      at weblogic.jms.JMSService.addJMSServer(JMSService.java:2167)
          >      at weblogic.jms.JMSService.addDeployment(JMSService.java:1938)
          >      at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:330)
          >      at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:201)
          >      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          >      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          >      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          >      at java.lang.reflect.Method.invoke(Method.java:324)
          >      at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:747)
          >      at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:726)
          >      at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:458)
          >      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
          >      at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
          >      at weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:765)
          >      at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(Unknown Source)
          >      at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:466)
          >      at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:409)
          >      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
          >      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
          >      at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:404)
          >      at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
          >      at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
          >      at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          > --------------- nested within: ------------------
          > weblogic.management.console.utils.SetException: An error occurred while updating
          > MigratableTarget on [Caching Stub]Proxy for dotnet:Name=CSJMSServer,Type=JMSServer
          > - with nested exception:
          > [weblogic.management.DistributedManagementException: Distributed Management [1
          > exceptions]
          > JMS JDBC store, connection pool = , prefix = : unsupported DBMS]
          >      at weblogic.management.console.actions.mbean.DoEditMBeanAction.perform(DoEditMBeanAction.java:311)
          >      at weblogic.management.console.actions.internal.ActionServlet.doAction(ActionServlet.java:173)
          >      at weblogic.management.console.actions.internal.ActionServlet.doPost(ActionServlet.java:85)
          >      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >      at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
          >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
          >      at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
          >      at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6310)
          >      at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
          >      at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
          >      at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
          >      at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
          >      at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
          >      at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          >
          >
          >
          > --------------------------------------------------------------------------------
          >
          > Console Release Build8.1.1.0Server Release Build8.1.1.0Server BuildWebLogic Server
          > 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 All Server Product VersionsWebLogic
          > Server 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 WebLogic XMLX Module 8.1 SP1
          > Fri Jun 20 23:06:40 PDT 2003 271009 WebLogic Server 8.1 SP1 Fri Jun 20 23:06:40
          > PDT 2003 271009 WebLogic Server 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003 271009 WebLogic
          > Portal 8.1 Thu Jul 10 20:09:22 PDT 2003 84868
          >

Effect of 'In-Memory' persistent store for JMS destinations

All,
We have many BPEL processes running on 1013 and we uses sensors to publish data into JMS-Topic destinations whose persistent store is 'In-Memory'.
when we bounce the oc4j (opmnctl stopall)
it always says one of components failed to stop
Shutting down forcefully...
Now my question is, If stopping oc4j is not graceful, Will my JMS messages be lost ?
regards,
Praveen

We are on soa 10133.
We see lot of problems with JMS In-Memory persistent store.
We have sensors in BPEL which publishes to JMS topics and we have BPEL as consumer which takes and inserts into database.
We see some times data getting inserted into data base and some times we do not see insertion though we dont see any errored bpels in console.
I suspect sensors are failing in publishing messages to topics becaz if consumer BPELs are failing we see them in console.
Anybody has any idea for what reasons sensors fails
and also what is performance impact if we use file-based JMS store?
Regards,
Praveen

JMS Message Buffer Size

Hi All,
          I am in need of some clarification regarding the following:
          According to the docs on:[url http://]http://edocs.bea.com/wls/docs92/perform/jmstuning.html#wp1149307
          The Message Buffer Size option specifies the amount of memory that will be used to store message bodies in memory before they are paged out to disk. The default value of Message Buffer Size is approximately one-third of the maximum heap size for the JVM, or a maximum of 512 megabytes.
          The question for me is: is the max of 512 megabytes, per weblogic server instance or per JMS server or per persistent store?
          Any help is greatly appreciated!
          -jeroen

Per JMS Server (the option is a JMS server option).
          Tom

What is the recommended way for persisting JMS messages?

What is the recommended way for persisting JMS messages?. As per the IMQ admin documentation , using the default built-in persistence type which is through unix flat files is much efficient and faster, compared to the database persistence .
Tried setting up the jdbc stuff for database persistence on iAS 6.5 . I am getting the following
error .
[24/Apr/2002:16:09:20 PDT] [B1060]: Loading persistent data...
[24/Apr/2002:16:09:21 PDT] Using plugged in persistent store: database connection
url=jdbc:oracle:thin:@dbatool.mygazoo.com:1521:qa1 brokerid=ias01
[24/Apr/2002:16:09:23 PDT] [B1039]: Broker "jmqbroker" ready.
[24/Apr/2002:16:11:56 PDT] ERROR [B4012]: Failed to persist interest
SystemManager%3ASystemManagerEngine%2BiMQ+Destination%0AgetName%28%29%3A%09%09SM_Response%0AClass%3A%09%09%09com.sun.messaging.Topic%0AgetVERSION%28%29%3A%09%092.0%0AisReadonly%28%29%3A%09%09false%0AgetProperties%28%29%3A%09%7BJMQDestinationName%3DSM_Response%2C+JMQDestinationDescription%3DA+Description+for+the+Destination+Object%7D:
java.sql.SQLException: ORA-01401: inserted value too large for column
[24/Apr/2002:16:11:56 PDT] WARNING [B2009]: Creation of consumer SM_Response to destination 1
failed:com.sun.messaging.jmq.jmsserver.util.BrokerException: Failed to persist interest
SystemManager%3ASystemManagerEngine%2BiMQ+Destination%0AgetName%28%29%3A%09%09SM_Response%0AClass%3A%09%09%09com.sun.messaging.Topic%0AgetVERSION%28%29%3A%09%092.0%0AisReadonly%28%29%3A%09%09false%0AgetProperties%28%29%3A%09%7BJMQDestinationName%3DSM_Response%2C+JMQDestinationDescription%3DA+Description+for+the+Destination+Object%7D:
java.sql.SQLException: ORA-01401: inserted value too large for column
Any thoughts?

From the output, you are using imq 2.0. In that release
the key used to persist a durable subscriber in the database
table has a limit of 100 characters. The output shows that
your value is:
SystemManager%3ASystemManagerEngine%2BiMQ+Destination%0AgetName%28%29%3A%09%09SM_Res
ponse%0AClass%3A%09%09%09com.sun.messaging.Topic%0AgetVERSION%28%29%3A%09%092.0%0Ais
Readonly%28%29%3A%09%09false%0AgetProperties%28%29%3A%09%7BJMQDestinationName%3DSM_R
esponse%2C+JMQDestinationDescription%3DA+Description+for+the+Destination+Object%7D:
which is much longer than 100 characters.
You might want to shorten the string you use for the
durable name.
And yes, the default file-based persistence store is
more efficient when compared to the plugged-in persistence
through a database.

Looking up a distributed queue with two persistent stores using two JMS Svr

I am trying to do the following:
1. Setup a distributed queue, i have two servers which are part of the cluster:
Server A: t3://localhost:7003
Server B: t3://localhost:7005
I go in and create two jms servers:
JMS Server JA: Target on Server A
JMS Server JB: Target on Server B
Now as the jms servers need to use a seperate persistent store for each one of them i create two persistent stores.
2. Now from my MDB which is deployed on another server i lookup the queue using
t3://localhost:7003,localhost:7005 as the provider url
My problem is that i always end up listening to the messages on the first jms server and never get to read the messages on jms server JB as i guess i am able to connect to JMS Server JA so i never try and connect to JB? What to do about this?
Edited by: user4828945 on Mar 23, 2009 2:32 PM

Allocation of consumers wouldn't take into account the number of messages on the queue - they'd be allocated randomly. The scenario you're proposing shouldn't happen though - WebLogic Server takes into account whether a member has consumers when sending to a distributed destination, but otherwise, assuming that Queue 1 and Queue 2 both have consumers, then distribution of load will be equal. It's not the amount of consumers that determine how many messages get sent to a distributed destination member - it's whether it has members at all.
Assuming that did occur initially though, you'd expect processing to be a little bit more intensive on the server with the queue holding 30 messages. It would pretty quickly even up though.
From that point forward, it would be somewhere between difficult and impossible to get to the second scenario, where you have an unequal number of messages in each distributed destination member, unless the work being sent with each message to an MDB can vary significantly in how long it would take to process.
Assuming (and it's a big if) you could get to that scenario, then the MDBs wouldn't switch over - they stay connected to a particular distributed destination member. And it's their connection to a member as a consumer that controls how WebLogic Server load balances messages (assuming default configuration) so that's part of what makes it unlikely to get there.
From going back to first principles in the documentation, it seems like your best result would actually be from deploying the MDB to the cluster - that way, there's no remote connections to JMS queues, and you get a pool of MDBs on each server instance.
Ref here: http://e-docs.bea.com/wls/docs81/ejb/message_beans.html

EntityManager.persist and JMS messaging issues?

Hi everyone:
I am seeing a problem that I could not figure out a solution. Can anyone shed me some lights on this?
I have a EJB method which basically does 2 things: 1). persists a record into a database table using EntityManager 2). sends out a message to a JMS topic. So it is th like:
myMethod() {
entityManager.persist(myObj);
notifier.notify(...);
The client will then listen to the JMS topic and read the new record from database. Usually this works pretty well, but sometimes, the client cannot find the new record from database at all and a few seconds later it can. It is as if there is a delay between the JMS messaging and database persistence - somehow the client receives the message first and at this time the record is not really saved into database yet!
Can anyone explain to me what is going on here? What kind of solutions might help to resolve this?
BTW, I am using the Hibernate EntityManager. My app server is Glassfish.
Thanks a lot for your help
jmao

You need to use flush method to persist the value before you calling notifier.notify(...);
below code should works
myMethod() {
entityManager.persist(myObj);
*entityManager.flush();</<br />
notifier.notify(...);
}

JMS Persistance Store "WLStore"

JMS Persistence Store was using WLStore table, to persist the JMS message, but on production server restart the Weblogic is not able to read that WLStore Table anymore and giving below Error.
<WebLogicServer> <BEA-000365> <Server state changed to STARTING>
<Error> <Store> <BEA-280072> <JDBC store "JMSJDBCStore" failed to open table "WLStore".
All help is appreciated.
Thanks
Anand.

Hi Anand,
There must be more information about this error in the log like a exception stacktrace. This error may come due to many reasons so complete error info would be required to identify the exact problem.
As it is a production issue so I would suggest you to raise a SR with support. Cross post your question in weblogic forum to get better response -
WebLogic Server - General
Regards,
Anuj

Weird things when persisting the jms messages of topic in the wls9?

I am testing the store of the jms messages in wls9.
          But when i sent a topic message to the topic, it seems that the message cannot be stored to the persistent stores.
          The things were that:
          when i send a message of queue and refreshed the page of console of wls9.I saw the number changed in :"Home > Summary of Persistent Stores > exampleJDBCStore "-Monitoring-Statistics,the "Create Count" had increased.
          But when i use the topic message, the "Create Count" never changed.
          Anybody can tell me why?
          Is the topic message cannot be stored in persistent stores, or others ?
          thx and rgds.

Topic messages are not persisted unless both the publisher qos is persistent and there are existing durable subscribers. Otherwise, there is no need to persist them. Do you have any durable subscribers?
          Tom

Removal of messages from persisted store

          Hi,
          If I'm using a JDBC store for my JMS server, are the messages removed from the
          DB when they are acknowledged? Are there config settings which play into this?
          Thanks,
          Bob


Elias Sinderson wrote:
          > Tom Barnes wrote:
          >
          >> An acknowledge deletes the associated
          >> messages from the store, whether
          >> it is a JDBC store or a file store. There is no config
          >> setting to turn off this behavior - and you are the first
          >> customer to ever ask if there was such a beast.
          >
          >
          > Actually, I looked for such a configuration but have been put in the
          > position of archiving JMS messages myself as this option is not provided
          > out of the box...
          Ah. Yes, I understand this use case. We are keeping it in mind
          for the future. The future solution may involve simply sending
          a duplicate message to another destination in the same
          transaction. The adminstrative interface might simply
          be something like an "ArchiveDestination" parameter on the
          original destination's configuration. Would that be sufficient?
          >
          > There are a number of reasons one may want to do wuch a thing, ranging
          > from record retention to simply allowing an end user to browse through
          > the set of delivered messages.
          I agree.
          > Personally, I believe that it is a
          > shortcoming of the JMS specification that it does not address this issue.
          Well pub/sub can address this issue. The drawback is that a durable
          subscriber is not the same as a queue - only one consumer can use
          it a time.
          >
          > The long and the short of it, in my case, is that I've now reimplemented
          > a good portion of the JMS specification on top of BEAs implementation.
          With WL, you can use standard JMS pub/sub to replicate messages
          and then use a messaging bridge to forward a subscription to a queue.
          This, of course, does not give great performance, but many applications
          are not sensitive to JMS performance.
          Another approach is to have senders send two messages, one to a
          pub/sub "monitoring" topic and one to the queue. Optionally
          using a transaction to ensure that it is atomic. Again, this is
          not a great performer.
          >
          >
          > Elias
          >
          Tom, BEA

JMS message persistance

Hi
I have an interface receiving SMS from a SMSC. This message is dumped into a JMS queue where a MDB receives and processes this.
This MDB relies on a DB connection writing a lot of information away and execute some PL/SQL.
Question is: When the DB is not available, ie the JDBC connection fails, how do I "re-send" this or save it to process it later when the DB is up again.
Is there any method available that will "auto re-submit" the JMS message if I don't acknowledge it?
The currentfunctionlaity works well except for this problem.
Tks
Andre

Isaac -- If you need high reliability or transactional behaviors you really need to be using Oracle JMS. In general we recommend using Oracle JMS for now becasue OC4J JMS is still not JMS 1.0.2 compliant. We are working on that for a future release.
Thanks -- Jeff

How can I make all my trash messaged be saved in trash folder?Mine only stores several days worth

I like to save all my deleted emails in case I want to go back down the road and find a deleted message .Seems thunderbird only stores trash for several days like today is 04-1-14 and I can only go back to 3-24-14 .Is there anyway to make it save all trash? Thanks Ben

Did you have this problem when checking your mail in a web browser? (Some providers automatically empty trash folders.)

The persistent store record 6,810 could not be found

Under heavy load, we get an exception stack trace in the log, that says that an expired message could not be deleted. This message is repeated every 15-30 minutes for other records. 5 hours later, it says that a thread is stuck and the server is blocked.
          What to do?
          We use Weblogic 9.2 MP2
          Thanks, Peter
          <Dec 17, 2007 7:19:48 PM MET> <Warning> <Messaging> <BEA-282006> <An error occurred while deleting an expired message for the messaging kernel datadispatcher-2/WeblogicJmsDistributedTopic@Remote@DataDispatc
          her JMS Module!datadispatcher-3@HandlerTopic@Local@DataDispatcher JMS Module!datadispatcher-2@HandlerTopic: weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not
          be found
          weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not be found
          at weblogic.store.internal.DeleteRequest.coalesce(DeleteRequest.java:55)
          at weblogic.store.internal.PersistentStoreImpl.coalesceRequests(PersistentStoreImpl.java:510)
          at weblogic.store.internal.PersistentStoreImpl.getOutstandingWork(PersistentStoreImpl.java:613)
          at weblogic.store.internal.PersistentStoreImpl.run(PersistentStoreImpl.java:621)
          at java.lang.Thread.run(Thread.java:595)
          >
          <Dec 17, 2007 7:19:48 PM MET> <Warning> <Messaging> <BEA-282006> <An error occurred while deleting an expired message for the messaging kernel datadispatcher-2/WeblogicJmsDistributedTopic@Remote@DataDispatc
          her JMS Module!datadispatcher-4@HandlerTopic@Local@DataDispatcher JMS Module!datadispatcher-2@HandlerTopic: weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not
          be found
          weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not be found
          at weblogic.store.internal.DeleteRequest.coalesce(DeleteRequest.java:55)
          at weblogic.store.internal.PersistentStoreImpl.coalesceRequests(PersistentStoreImpl.java:510)
          at weblogic.store.internal.PersistentStoreImpl.getOutstandingWork(PersistentStoreImpl.java:613)
          at weblogic.store.internal.PersistentStoreImpl.run(PersistentStoreImpl.java:621)
          at java.lang.Thread.run(Thread.java:595)
          >
          <Dec 17, 2007 7:19:48 PM MET> <Error> <Store> <BEA-280074> <The persistent store "datadispatcher-fs-2" encountered an unresolvable failure while processing transaction "BEA1-0A0CD965B4DAECF2346C". Shutdown
          and restart to resolve this transaction. weblogic.store.gxa.GXAException: weblogic.store.PersistentStoreException: weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 co
          uld not be found
          weblogic.store.gxa.GXAException: weblogic.store.PersistentStoreException: weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not be found
          at weblogic.store.gxa.internal.GXAResourceImpl.registerFailedTransaction(GXAResourceImpl.java:597)
          at weblogic.store.gxa.internal.GXATransactionImpl.doOperationCallbacks(GXATransactionImpl.java:243)
          at weblogic.store.gxa.internal.GXAResourceImpl.commit(GXAResourceImpl.java:1451)
          at weblogic.transaction.internal.XAServerResourceInfo.commit(XAServerResourceInfo.java:1333)
          at weblogic.transaction.internal.XAServerResourceInfo.commit(XAServerResourceInfo.java:577)
          at weblogic.transaction.internal.ServerSCInfo.startCommit(ServerSCInfo.java:486)
          at weblogic.transaction.internal.ServerTransactionImpl.localCommit(ServerTransactionImpl.java:1993)
          at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:2658)
          at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:2580)
          at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:278)
          at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
          at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:463)
          at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:335)
          at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:291)
          at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4072)
          at weblogic.jms.client.JMSSession.execute(JMSSession.java:3962)
          at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4490)
          at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
          at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
          at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
          weblogic.store.PersistentStoreException: weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not be found
          at weblogic.store.gxa.internal.GXATransactionImpl.commitStoreIO(GXATransactionImpl.java:103)
          at weblogic.store.gxa.internal.GXATransactionImpl.doOperationCallbacks(GXATransactionImpl.java:215)
          at weblogic.store.gxa.internal.GXAResourceImpl.commit(GXAResourceImpl.java:1451)
          at weblogic.transaction.internal.XAServerResourceInfo.commit(XAServerResourceInfo.java:1333)
          at weblogic.transaction.internal.XAServerResourceInfo.commit(XAServerResourceInfo.java:577)
          at weblogic.transaction.internal.ServerSCInfo.startCommit(ServerSCInfo.java:486)
          at weblogic.transaction.internal.ServerTransactionImpl.localCommit(ServerTransactionImpl.java:1993)
          at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:2658)
          at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:2580)
          at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:278)
          at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
          at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:463)
          at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:335)
          at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:291)
          at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4072)
          at weblogic.jms.client.JMSSession.execute(JMSSession.java:3962)
          at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4490)
          at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
          at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
          at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
          weblogic.store.PersistentStoreException: [Store:280029]The persistent store record 6,810 could not be found
          at weblogic.store.internal.DeleteRequest.coalesce(DeleteRequest.java:55)
          at weblogic.store.internal.PersistentStoreImpl.coalesceRequests(PersistentStoreImpl.java:510)
          at weblogic.store.internal.PersistentStoreImpl.getOutstandingWork(PersistentStoreImpl.java:613)
          at weblogic.store.internal.PersistentStoreImpl.run(PersistentStoreImpl.java:621)
          at java.lang.Thread.run(Thread.java:595)
          >
          <Dec 17, 2007 7:19:48 PM MET> <Error> <EJB> <BEA-010026> <Exception occurred during commit of transaction Xid=BEA1-0A0DD965B4DAECF2346C(14187897),Status=Rolled back. [Reason=javax.transaction.xa.XAException
          ],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=60,XAServerResourceInfo[WLStore_deplDomain_datadispatcher-fs-2]=(ServerResourceInfo[WLStore_deplDomain_datadispatcher-fs-2]=(st
          ate=rolledback,assigned=deplMan2),xar=WLStore_deplDomain_datadispatcher-fs-25927290,re-Registered = false),XAServerResourceInfo[datadispatcher-multipool]=(ServerResourceInfo[datadispatcher-multipool]=(state
          =rolledback,assigned=deplMan2),xar=datadispatcher-multipool,re-Registered = false),SCInfo[deplDomain+deplMan2]=(state=rolledback),local properties=({weblogic.jdbc.jta.datadispatcher-multipool=[ No XAConnect
          ion is attached to this TxInfo ]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=deplMan2+141.249.2.220:28200+deplDomain+t3+, XAResources={NetworkControl, WeblogicTimerService
          , datadispatcher-xa-standby, datadispatcher-multipool, WLStore_deplDomain_datadispatcher-fs-2, datadispatcher-xa-active},NonXAResources={})],CoordinatorURL=deplMan2+141.249.2.220:28200+deplDomain+t3+): webl
          ogic.transaction.RollbackException: Could not prepare resource 'WLStore_deplDomain_datadispatcher-fs-2
          at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1809)
          at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:331)
          at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:227)
          at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:463)
          at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:335)
          at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:291)
          at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4072)
          at weblogic.jms.client.JMSSession.execute(JMSSession.java:3962)
          at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4490)
          at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
          at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
          at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
          <Dec 18, 2007 12:33:44 AM MET> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "643" seconds working on the request "we
          blogic.work.ServerWorkManagerImpl$WorkAdapterImpl@7aca93", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
          sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          java.lang.reflect.Method.invoke(Method.java:585)
          net.sf.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:96)
          net.sf.hibernate.persister.AbstractEntityPersister.getIdentifier(AbstractEntityPersister.java:306)
          net.sf.hibernate.impl.SessionImpl.checkId(SessionImpl.java:2636)
          net.sf.hibernate.impl.SessionImpl.flushEntity(SessionImpl.java:2461)
          net.sf.hibernate.impl.SessionImpl.flushEntities(SessionImpl.java:2454)
          net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2256)
          net.sf.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1801)
          net.sf.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:1567)
          net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1532)
          net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:39)
          ch.meteoswiss.datadispatcher.model.dao.TimedMessageDAO.findByMeteodata(TimedMessageDAO.java:232)
          ch.meteoswiss.datadispatcher.model.dao.TimedMessageDAO.deleteByMeteodata(TimedMessageDAO.java:263)
          ch.meteoswiss.datadispatcher.model.dao.MeteodataDAO.delete(MeteodataDAO.java:482)
          ch.meteoswiss.datadispatcher.model.base.BaseMeteodataDAO.delete(BaseMeteodataDAO.java:194)
          ch.meteoswiss.datadispatcher.model.dao.MeteodataDAO.deleteOutdated(MeteodataDAO.java:432)
          ch.meteoswiss.datadispatcher.timed.CleanUpListener.deleteOutdatedMeteodataEntries(CleanUpListener.java:88)
          ch.meteoswiss.datadispatcher.timed.CleanUpListener.handleNotification(CleanUpListener.java:141)
          weblogic.management.timer.TimerListener$1.run(TimerListener.java:48)
          weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
          weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
          weblogic.management.timer.TimerListener.deliverNotification(TimerListener.java:44)
          weblogic.management.timer.Timer.deliverNotifications(Timer.java:440)
          weblogic.management.timer.TimerNotification$1.run(TimerNotification.java:124)
          weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
          weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
          weblogic.management.timer.TimerNotification.timerExpired(TimerNotification.java:121)
          weblogic.timers.internal.TimerImpl.run(TimerImpl.java:265)
          weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
          weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
          weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
          >

Please find below an extract of the Java trace (kill -3 on Unix):
          "[STUCK] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=1 tid=0x00440ef8 nid=0x34 in Object.wait() [0x85800000..0x85801808]
          at java.lang.Object.wait(Native Method)
          at java.lang.Object.wait(Object.java:474)
          at weblogic.messaging.dispatcher.Request.sleepTillNotified(Request.java:324)
          at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:801)
          - locked <0xb3288670> (a weblogic.jms.backend.BEProducerSendRequest)
          at weblogic.messaging.dispatcher.DispatcherImpl.dispatchAsyncInternal(DispatcherImpl.java:129)
          at weblogic.messaging.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:112)
          at weblogic.messaging.dispatcher.Request.dispatchAsync(Request.java:1046)
          at weblogic.jms.dispatcher.Request.dispatchAsync(Request.java:72)
          at weblogic.jms.frontend.FEProducer.doDispatch(FEProducer.java:880)
          at weblogic.jms.frontend.FEProducer.sendRetryDestination(FEProducer.java:1010)
          at weblogic.jms.frontend.FEProducer.send(FEProducer.java:1383)
          at weblogic.jms.frontend.FEProducer.invoke(FEProducer.java:1444)
          at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:759)
          at weblogic.messaging.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:246)
          at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncNoTran(DispatcherAdapter.java:59)
          at weblogic.jms.client.JMSProducer.toFEProducer(JMSProducer.java:1061)
          at weblogic.jms.client.JMSProducer.deliveryInternal(JMSProducer.java:670)
          at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:455)
          at weblogic.jms.client.JMSProducer.send(JMSProducer.java:337)
          at weblogic.jms.client.WLProducerImpl.send(WLProducerImpl.java:966)
          at ch.meteoswiss.datadispatcher.receiver.ReceiverServlet.sendJMSMessage(ReceiverServlet.java:255)
          at ch.meteoswiss.datadispatcher.receiver.ReceiverServlet.doProcess(ReceiverServlet.java:320)
          at ch.meteoswiss.datadispatcher.receiver.ReceiverServlet.doPost(ReceiverServlet.java:297)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
          at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
          at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
          at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
          at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
          at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3231)
          at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
          at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
          at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2002)
          at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1908)
          at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1362)
          at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
          at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
          The method in ReceiverServlet:
                    private static void sendJMSMessage(MeteodataTransfer data) throws NamingException, JMSException {
                  QueueConnection queueConnection = null;
                  QueueSession jmsSession = null;
                  QueueSender jmsSender = null;
                  try {
                      final ServiceLocator initial = ServiceLocator.getInstance();
                      final QueueConnectionFactory factory = (QueueConnectionFactory)initial.lookup(ServiceLocator.CONNECTION_FACTORY); //"java:comp/env/jms/QUEUEFACTORY");
                      final Queue queue = (Queue)initial.lookup("java:comp/env/jms/"+data.getSubscriber().getOutputQueueTx().toUpperCase());
                      queueConnection = factory.createQueueConnection();
                      jmsSession = queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
                      jmsSender = jmsSession.createSender(queue);
                      final ObjectMessage msg = jmsSession.createObjectMessage();
                      msg.setJMSExpiration(...);
                      msg.setObject(data);
                      jmsSender.send(msg); // LINE 255!!! STUCK!!!
                  } finally {
                      JmsUtil.closeQuietly(jmsSender);
                      JmsUtil.closeQuietly(jmsSession);
                      JmsUtil.closeQuietly(queueConnection);

Undelivered JMS messages get deleted on startup. Why?

          WebLogic 6.1 (SP2), NT4 (SP6), native IO enabled.
          Here's what happens:
          1. A JMS client posts a number of messages (say 8000) to a Weblogic JMS queue backed
          up by a database store.
          2. The JMS consumer (i.e. Message driven bean's onMessage()) is slow - it has 5 seconds
          of processing to do for each message.
          3.The JMS monitoring screens show 100 messages have been processed - this is ok;
          the client can post much faster than the server can consume. This would imply 7900
          messages undelivered.
          4. We do a controlled shutdown of the server.
          5. A select count(*) from JMS_JMSStore reveals all 8000 messages have been persisted.
          6. We start up the server. The JMS recovery message in weblogic.log indicates that
          a scan of 8000 records has been made.
          7. I would now expect 7900 undelivered messages to be passed to the mdb's onMessage()
          method (remember before shutdown, 100 messages were processed by onMessage()).
          8. This doesn't happen; onMessage() gets nothing, and a select count(*) from JMS_JMSStore
          reveals zero records! Why have these messages been deleted?
          Presumably on startup, the JMS recovery tries to ensure that the JMS store only holds
          messages that have yet to be delivered. But in this case it's deleteing everything.
          Note that there are no error messages or stack traces to report.
          Any ideas, anyone?
          simon.


It has to be durable, or there wouldn't be anything in the store.
          What happens if you undeploy and redeploy the MDB (instead of shutting
          down)? Do your messages have a time-to-live? Your configuration has not
          changed? Try it without the MDB. That is just a program that creates
          durable subscriber. Have it receive 100
          messages. Shutdown the server and restart, then restart the durable
          subscriber program. This would prove it is JMS or if the MDB container is
          doing something ugly like an unsubscribe.
          _sjz.
          "DanS" <[email protected]> wrote in message
          news:[email protected]...
          > Simon,
          >
          > The JMS consumer, is it created as a durable subscriber? As far as I knoe,
          > weblogic will keep the messages in the queue / topic only if the consumer
          is
          > registered as a durable subscriber.
          >
          > Dan
          >
          > "Simon Spruzen" <[email protected]> wrote in message
          > news:[email protected]...
          > >
          > > WebLogic 6.1 (SP2), NT4 (SP6), native IO enabled.
          > >
          > > Here's what happens:
          > >
          > > 1. A JMS client posts a number of messages (say 8000) to a Weblogic JMS
          > queue backed
          > > up by a database store.
          > >
          > > 2. The JMS consumer (i.e. Message driven bean's onMessage()) is slow -
          it
          > has 5 seconds
          > > of processing to do for each message.
          > >
          > > 3.The JMS monitoring screens show 100 messages have been processed -
          this
          > is ok;
          > > the client can post much faster than the server can consume. This would
          > imply 7900
          > > messages undelivered.
          > >
          > > 4. We do a controlled shutdown of the server.
          > >
          > > 5. A select count(*) from JMS_JMSStore reveals all 8000 messages have
          been
          > persisted.
          > >
          > > 6. We start up the server. The JMS recovery message in weblogic.log
          > indicates that
          > > a scan of 8000 records has been made.
          > >
          > > 7. I would now expect 7900 undelivered messages to be passed to the
          mdb's
          > onMessage()
          > > method (remember before shutdown, 100 messages were processed by
          > onMessage()).
          > >
          > > 8. This doesn't happen; onMessage() gets nothing, and a select count(*)
          > from JMS_JMSStore
          > > reveals zero records! Why have these messages been deleted?
          > >
          > > Presumably on startup, the JMS recovery tries to ensure that the JMS
          store
          > only holds
          > > messages that have yet to be delivered. But in this case it's deleteing
          > everything.
          > >
          > > Note that there are no error messages or stack traces to report.
          > >
          > > Any ideas, anyone?
          > >
          > > simon.
          > >
          >
          >

JMS messages stuck in queue in weblogic v923 cluster

Hi all,
Enviornment details:
In our pre-production weblogic v923 cluster enviornment with Oracle 10g database, there are 10 server boxes with 2 managed nodes running on each server box in linux enviornment.
There are 3 JMS queues and 1 error queue per managed node.
All the queues are durable and the persitence store is a database table. There is a single database table per single managed node.
High loads of JMS messages from client applications coming on each of the 3 JMS queue are processed by the cluster on daily basis.
The JMS messages that failed to be processed the very first time due to the application logic exceptions are put on error queue since the retry is set to zero on the non-error queue.
The application exceptions are logged to a database table for futher reference.
The falied messages from the error queue are read by spring based MDP and resent to the application for reprocessing.
If no application exceptions, the message will be persisted in a relational database; in the case of failures, MDP code puts the failed message back on to the error queue.
The auto_ack is true on the JMS message.
It is observed about less than 1% of the messages fail the original processing and are in error queue on daily basis.
99.9% of the time, the reprocessing of the messages from the error queue is a success.
Currently due to some obvious reasons, the system administrator stops a managed node when the disk is full and start a different managed node on the same server box. This approach will be stopped in the very near future so that all nodes on all servers are running at any point of time by making few enviornment changes.
Problem:
1a) Occasionally, it is observed that 1 - 4 JMS messages are stuck in the error queue. There are no signs of reprocessing as there are no application exceptions or the corresponing insert into the database. The JMS persistence store table still has the JMS message.
1b) It is observed that over time, the same JMS messages that were originally stuck on server 1's managed node A are no longer there but are found in a different node (say node B) on a different server box.
As far as I understand the JMS, a message could be in a Pending state if MDP (in my case) does not automatically send ACKNOWLEGMENT back due to an issue in the Spring Defaultlisternercontainer before calling MDP's onMessage(). I am not sure as what happens to that status over time).
It is also observed that the stuck messages content is not much different than the other messages that are processed fine.
Any pointers/input is highly appreciated.
Thanks in advance for your valuable input and time.

Off the top of my head, I can only think of two reasons why a message might move from node to node:
(A) An application is dequeueing them and enquening them elsewhere.
(B) The application is using distributed queues, and the distributed queue has been configured to enable "queue forwarding". The forwarding feature automatically moves messages from distributed queue members that have no consumers to members that do have consumers. Queue forwarding is sometimes enabled as a work-around to better enable MDP support of WL distributed destinations, unlike WebLogic MDBs, MDPs have no container logic to ensure that all members of a distributed destination are serviced by a consumer under all circumstances...
Regards,
Tom

Saving a JMS Message in a Persistent Store

Similar Messages

Maybe you are looking for