4 Replies Latest reply on Aug 30, 2011 10:42 AM by Ryan Hochstetler

    jboss 5.1 & messaging & Oracle 11g

    naz0 Newbie

      Hi all,


      I am using jboss messaging with Oracle 11g for persistence.

      When I use massively JBM queues; the tablespace dedicated for jboss is growing. After some search I foud that the LOBSEGMENT linked to the column PAYLOAD of the table JBM_MSG is taking 99% of the tablespace. The table JBM_MSG is empty but I have a lob segment linked to this table.


      I am not a jboss dev, and I don't know what is payload column for. I even don't know what is a lob segment ... but is anybody have already seen this problem and fixed it ?

        • 1. Re: jboss 5.1 & messaging & Oracle 11g
          naz0 Newbie

          It seems that I am the only one seeing this issue :/

          • 2. Re: jboss 5.1 & messaging & Oracle 11g
            Ryan Hochstetler Newbie

            We're seeing the exact same issue under a nearly identical configuration.  Our DBA is gone for the day so I can't ask him what fix he put in place, but I can nearly guarantee that the problem is the configuration of Oracle (or the objects therein, rather), not JBoss Messaging.  I suspect it has to do with fragmentation of the lobsegment.  Our JBM_MSG sees about 20 million messages come and go per day, so there's lots of volatility in that table, which is a key ingredient for fragmentation.

            1 of 1 people found this helpful
            • 3. Re: jboss 5.1 & messaging & Oracle 11g
              naz0 Newbie

              Hi Ryan,


              Thanks for your response. I will be happy if you can get more info from your dba.

              I will try to investigate the oracle part.

              • 4. Re: jboss 5.1 & messaging & Oracle 11g
                Ryan Hochstetler Newbie

                Our DBA told me that it's a bug in 11g, but it's easily fixed.  The solution is to enable an event in the init.ora file and reboot the system.  It didn't sound like you had a full-time DBA for your project, so I got a few simple instructions from our DBA to help you out.

                1. create pfile from spfile
                2. modify pfile to include the event
                3. startup using new pfile
                4. create spfile from the new pfile  to put new event into spfile for next reboot


                44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024


                This fix causes ASSM LOB space to batch up reclaim instead of just  reclaiming the requested/required number of LOB chunks. To enable this  fix, set event 44951 to the maximum number of chunks that you would like  to have reclaimed per attempt. The maximum allowed is 1024. Anything  larger becomes 1024. However, if the requested amount of space is larger  than the event’s value, the reclaim will be for the requested amount of  space.


                Good luck!