3

For my web app, I have a JMS topic which is receiving many messages at any given time. I have a MDB that processes the messages and updates the database based on the message data. I had been getting org.hibernate.exception.LockAcquisitionException when the topic was receiving multiple messages all at the same time so I changed the maxSessions attribute for the MDB to 1 and made it a singleton.

Now I am not seeing the Hibernate exceptions anymore, but I have concerns about performance. How large can I expect the Topic to get before I start seeing problems? I am using JBoss 4.3 EAP and I tried searching for how to configure this but nothing turned up. Will the topic size grow until Java runs out of memory or is this something that can be configured in JBoss?

skaffman
  • 398,947
  • 96
  • 818
  • 769
BennyMcBenBen
  • 1,438
  • 2
  • 20
  • 37

2 Answers2

1

By default, JBoss Messaging will store its messages in an embedded Hypersonic database. If your topic starts filling up, your memory consumption shouldn't increase linearly, but sooner or later the database will fill up (from what I recall, Hypersonic has a 40,000 row limit, in this configuration at least).

More generally, if you're producing messages faster than you're consuming them, then you have a problem. You either need to produce them more slowly, consumer them more quickly, or work out a way of discarding messages.

skaffman
  • 398,947
  • 96
  • 818
  • 769
  • Thanks. We are using MS SQL Server 2008 for the JBoss DefaultDS data source instead of Hypersonic, but I assume the constraints are similar. I will be sure to run stress tests on my implementation to see if there are any problems like you are describing. – BennyMcBenBen May 11 '11 at 15:31
0

How many messages can be queued up in a JMS topic?

Would depend of the available memory or disk space, would depend of the JMS vendor and the queue configuration.

But concerning purely performance of updating to the database, you should do batch processing. (Even with only one thread). Get X message at a time, process them all, and send the batch update to the database using the same transaction. Chances are your database can update/update 100 or 1000 row in nearly the same amount of time as 1 row.

On a side note, are you concerned by performance at all ? Is it too slow right now?

skaffman
  • 398,947
  • 96
  • 818
  • 769
Nicolas Bousquet
  • 3,990
  • 1
  • 16
  • 18
  • Thanks for the database processing tip. The end user expects something close to real time updates in the database so we have not looked at batch or delayed processing so far. I am not sure if I am concerned about performance yet. I will need to verify that it meets the customer's requirements. – BennyMcBenBen May 11 '11 at 15:33