[jboss-user] [JBoss Messaging] - Re: messages stuck in queues
do-not-reply at jboss.com
Tue Mar 4 08:00:45 EST 2008
Tim Fox's reply inline:
anonymous wrote : >
| > Just a bit of background.
| > We've been running with EAP 4.2 and JBM 1.4.0.GA for a while. I'm quite
| > aware this is not the environment supported by Red Hat, but this is what
| > we have and we've been on a steady path to becoming 100% compliant: We
| > were running JBoss 4.2.1 GA and ActiveMQ, replaced ActiveMQ with JBM and
| > then took on Red Hat support. At this point we upgraded to JBoss EAP 4.2
| > (but kept JBM in place). I've been working on a branch running JBoss EAP
| > 4.3 and the default configured JBM 1.4.0.SP3, however this is not yet
| > deployed into production. We had a couple of issue with JBM 1.4.0.GA (or
| > really JBoss Remoting I should say) which was sorted out by using a
| > slightly modified version of the remoting-biscoket-service.xml that
| > bundles with JBM 1.4.0.SP3. Please note we were still at this time using
| > the JBM 1.4.0.GA libraries. However, as JBM 1.4.0.SP3 is the stable
| > release, we heeded a suggestion by Red Hat and decided to upgrade.
| > That's when the problem occurred.
| > As already mentioned, I'm going to run a couple of experiments today to
| > see whether I can narrow down the reason for the problem. I'm not yet
| > convinced it is a bug in JBM. My reasons are:
| I don't want to speculate too much at this point, but 1.4.0.SP3 is our
| most highly tested JBM release - having gone through rigorous load and
| soak test with our QA department before it was allowed to go in the EAP.
| So a bug of this magnitude slipping through the net would surprise me,
| although, of course we can't rule this out.
| > 1. We used the same JBM database schema from 1.4.0.GA.
| > This did not give
| > any problems when we tested in the dev environments. However, after more
| > careful inspection of the SQL in oracle-persistence.sql I noticed a
| > couple of changes were in place (e.g. new index, delete_message sql
| > script switched order of parameters arround ... this could be problem is
| > JBM is not using name parameters, but positional,
| > supports_blob_on_select flag, composite primary key for JBM_MSG_REF
| > changed declaration order for composite columns, etc). I don't know if
| > this could be the cause of our problem and the old schema certainly
| > worked fine for us in the development environment, but I'll try and use
| > the new schema and see whether that makes a difference.
| Yes the schema has changed between GA and SP3. It is critical that the
| old database is dropped before installing the new version, otherwise all
| kinds of strange problems might occur.
| > 2. The following customisations were dropped from
| > connection-factories-service.xml
| > Setting attribute PrefetchSize to 1000.
| > Setting attribute SlowConsumers to false.
| This may cause behavioural differences w.r.t message consumption.
| > 3. Were PostOffice was marked as not clustered before, it was deployed
| > as clustered this time round (default from bundled
| > oracle-persistence-service.xml). Do not anticipate this to be a problem
| > since we are running just a single node.
| Best to set clustered = false though if you are running a single node.
| > 4. Using EAP 4.3 build for JBR 2.2.2.SP4 --- Implementation-Version:
| > 4.3.0.GA (build: VNTag=JBPAPP_4_3_0_GA date=200801031548) instead of the
| > BREW library. I reckoned the EAP 4.3 one would be most stable since
| > tested by Red Hat. However, perhaps there are modifications specific to
| > EAP 4.3.
| Yes, that is a possibility. The EAP versions of a product and the
| community version of the product can and do diverge sometimes, this is
| mainly because we can provide bug fixes etc on the EAP version that's
| not available on the free version until a later date. Not sure if this
| applies to those versions of JBR but it's possibility. To be safe, it's
| always wise not to mix and match version from the EAP and community
| If you want to run JBM 1.4.0.SP3 inside EAP 4.2, you should obtain the
| JBM jar from the download on the labs site:
| And the JBoss Remoting version should be obtained from here:
| To summarise, in order to upgrade versions, you should follow the
| following steps:
| 1) Drop the old database
| 2) Obtains the distro and jars from above urls.
| 3) Replace jboss-messaging.jar in the app server in the
| server/messaging/lib directory with the one inside the distro. (assuming
| you have named your server profile "messaging")
| 4) Replace jboss-remoting.jar in the app server in the
| server/messaging/lib directory with the one download from the above url.
| 5) Replace all *.xml files in
| server/messaging/deploy/jboss-messaging.sar/ with their equivalents from
| the JBM distro you downloaded.
| 6) Re-apply any custom changes (e.g. prefetchSize, slowConsumers etc)
| that you made in your previous installation to those files. (There have
| been config changes between GA and SP3)
| 7) If you are using ServiceBindingManager service in JBoss AS, update
| the JBM remoting configuration section in the SBM config to exactly
| reflect the new JBR config.
| 8) For every client that connects to JBM, need to update make sure the
| new jboss-messaging-client.jar and new jboss-remoting.jar that you
| downloaded are on the client classpath *before* any other jars.
| As you can see it's a bit fiddly, but a simple replace the jars almost
| certainly won't work.
| Alternatively, If you are willing to recreate your server profile, you
| could just the automated install instructions from the user guide. But
| I'm not sure if you're able to do that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133886#4133886
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133886
More information about the jboss-user