We are experiencing the below exception on our JBoss 3.2.1 Server. Other messages in the forum have attributed this exception to having
more than one JBoss instance interacting with the JMS_Messages file, this
is not the case on our production server.
Could someone articulate what the .-2147483616 (see exception trace) in TOPIC.GPRS.KermitMessageClient.-2147483616 refers to. We have
a KermitMessageClient destination configured within JMS but the
"temporary" destinations are continually appearing in the messages file
and are the source of the exception. We have never seen any contention
on the actual KermitMessageClient destination.
seems very like the problem we are experiencing, could it be the same
We are considering deleting the temporary destination from the production
database but are reluctant to do so until we know what these destinations
The system has been in production for several months now and the error is getting increasingly frequent which again is somethinh we don't understand, the application code has been very stable in that time.
2004-04-21 10:03:35,968 [MessageListenerThread - GPRS] ERROR com.celtrak.jms.Publisher - org.jboss.mq.SpyJMSException: Could not store message: 142010 msg=78714 hard NOT_STORED PERSISTENT queue=TOPIC.GPRS.KermitMessageClient.-2147483616 priority=4 hashCode=12204633; - nested throwable: (java.sql.SQLException: [Microsoft][SQLServer JDBC Driver][SQLServer]Violation of PRIMARY KEY constraint 'PK__JMS_MESSAGES__095F58DF'. Cannot insert duplicate key in object 'JMS_MESSAGES'.)
2004-04-21 10:03:35,968 [MessageListenerThread - GPRS] ERROR com.celtrak.jms.Publisher - org.jboss.mq.pm.jdbc2.PersistenceManager.saveToStorage(PersistenceManager.java:1164)
There is a bug in 3.2.1 (fixed in 3.2.3) where messages left in temporary destinations
were not getting deleted. They would likely end up in the cache store with a
TX_OP of 'T'.
A server restart should delete them, it deletes all 'T'=temporary records
during the recovery process.
Which part is not working for you?
We have another crash this morning which forced our hand and we deleted the "temporary destinations". The systems is running for
1 hour so far and we have seen no "temporary destinations" created
yet. We will monitor the server and try and get an answer to your
question. Our experience was that temporary records were surviving
restarts, though I am not sure what the TX_OP field were.
Do entries in the JMS_Message file such as TOPIC.GPRS.KermitMessageClient.-2147483616 refer to Temporary subscribers and when are they created.
Currently our Application restarts when we experience this exception, is
this overkill or can the JMS Persistance Manager eventually recover from
The symptoms you report are exactly the problem that was fixed in 3.2.3
1) Start a client VM - and connect using a ClientID
2) Send messages to a temporary queue/topic but don't receive them
3) Don't close the connection properly, leaving the server to try to tidy up for you
(it does not - it doesn't delete the messages in the temporary queue)
4) Repeat from (1)
The other part to reproduce the problem is that the message cache must have
softened the undeleted temporary messages into the db. i.e. at some point
JBossMQ thought you were running low on memory.
If this is not your problem (try it on 3.2.3), then please include an analysis
similar to what I have done above.
The persistence manager cannot recover from the problem. Everytime you
start a client (new VM) with the same client id, it will try to use the same
key for the temporary destinations, but there are still records lying around from
the previous client to confuse it.