[JBoss Messaging] - Re: deleting messages rather than blocking if server down fo
by timfox
Adrian-
Are your client threads calling send() on the same ClientProducer (core ) or MessageProducer (JMS) instance? If you do this you would have to synchronize access in your client application since neither JMS MessageProducers or core ClientProducer instances are designed to be used by more than one thread at a time,
Alternatively if you're creating a new MessageProducer for each message sent - that would also be frowned upon as an anti-pattern. Sessions/Producers/Consumers should always be reused between messages sent/consumed (unless you're not worried about performance).
If you enable auto reconnect you do so on the presumption that your server has not really failed but there is a temporary network glitch (like someone has pulled out the cable for a while), and when the network comes back the client will be able to automatically reconnect its session(s) with the sesssion(s) still remaining on the server and carry on as if nothing had happened (this is transparent reconnection). In your case the server has really failed so on recovery the server sessions will clearly not be there any more (since the server was restarted) and they won't be able to connect. That's why you don't get the exception until the client has tried to reconnect and not found the session(s) there. If you turn off auto reconnection you'll get the exception sooner.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242372#4242372
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242372
17 years
[JBoss Messaging] - Re: deleting messages rather than blocking if server down fo
by AdrianWoodhead
The threads are coming from my client application - there is a thread per http request and at the end of the request it calls send(). Hundreds of these threads are created every minute so if the call to send() blocks then it doesn't take long for the blocking to overwhelm the VM. I guess I could re-architect my application to put the messages in a queue and have one thread pull the messages off and send them, this just feels a bit like I'm implementing something which could (should?) be in the messaging client.
As for the ExceptionListener solution, I thought about this too. I have JBM setup to auto-reconnect so I don't actually get an exception when the server goes down (I just see some warning messages in the logs). From what I can tell the sender queues up the messages in the background. When the server comes back, only then does my ExceptionListener callback get called, at which point I redo the JNDI lookup and recreate the connections and sessions etc. This works well. I think if I set JBM not to auto-connect then the ExceptionListener callback is called right away when the server goes down, but then I have to do my own reconnect logic. I'm happy with this ExceptionListener logic, it would just be nice to be able to throw messages away instead of blocking, but maybe I should code this up myself.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242366#4242366
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242366
17 years
[Management, JMX/JBoss] - Re: Problem with deployment listener when moving from JBoss
by vit.jonas
I used following MBean listening on EJB3 deployments in JBoss 4.2 (jboss-service.xml):
| <server>
| <!-- EJB notification listener -->
| <mbean code="my.project.mbeans.EJBDeployNotificationListener" name="my.project.mbeans:service=EJBDeployNotificationListener">
| <attribute name="SubscriptionList">
| <subscription-list>
| <mbean name="jboss.ejb3:service=EJB3Deployer" handback="ejb3Deployer"/>
| <notification type="START_NOTIFICATION" />
| <notification type="STOP_NOTIFICATION" />
| </subscription-list>
| </attribute>
| </mbean>
| </server>
|
my.project.mbeans.EJBDeployNotificationListener implements ListenerServiceMBeanSupport. In Jboss 4.2 I'm able to look to all deployed artifacts and do what I need with it. In this case for parsing specific proprietary annotations for our customer EJB3 classes.
There isn't any service jboss.ejb3:service=EJB3Deployer in JBoss 5.1.0 all configuration (clean installation). I tried to explore jboss.deployment:id="Ejb3Deployer",type=Component but it seems to not provide any notification support. I guess it is because in JBoss 5 this should be handled in a different way.
Can you give me some advise how to solve this task?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242360#4242360
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242360
17 years
[Persistence, JBoss/CMP, Hibernate, Database] - Arjuna TX Manager Class Cast Exception
by rupertlssmith
Hi,
On JBoss 4.2.2GA, I get the following exception:
java.lang.ClassCastException: com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate cannot be cast to javax.transaction.TransactionManager
| at org.hibernate.transaction.JNDITransactionManagerLookup.getTransactionManager(JNDITransactionManagerLookup.java:23)
| at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:325)
| at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1300)
Another Forum post suggested this might be because of having the 'jta' jar in the .ear file I am trying to deploy. I checked and sure enough it was there as part of the hibernate dependencies I included. 'jta.jar' does not need to be in the .ear file as the app server already provides it. So I removed it, but I still get the above error.
So now my dependency set of jars that are in my .ear file looks like (created with mvn dependency:tree):
[dependency:tree]
| [INFO] uk.co.thebadgerset:thecookerybook-dev:ear:0.3-SNAPSHOT
| [INFO] +- uk.co.thebadgerset:thecookerybook-backend:jar:0.3-SNAPSHOT:compile
| [INFO] | +- uk.co.thebadgerset:common:jar:0.3-SNAPSHOT:compile
| [INFO] | | +- log4j:log4j:jar:1.2.13:compile
| [INFO] | | +- regexp:regexp:jar:1.3:compile
| [INFO] | | +- xml-apis:xml-apis:jar:1.3.03:compile
| [INFO] | | +- dom4j:dom4j:jar:1.6.1:compile
| [INFO] | | +- xerces:xercesImpl:jar:2.8.0:compile
| [INFO] | | \- xalan:xalan:jar:2.7.0:compile
| [INFO] | +- uk.co.thebadgerset:configurator:jar:0.3-SNAPSHOT:compile
| [INFO] | | +- javax.xml.bind:jsr173_api:jar:1.0:compile
| [INFO] | | +- javax.xml.bind:jaxb-api:jar:2.1:compile
| [INFO] | | | +- javax.xml.stream:stax-api:jar:1.0-2:compile
| [INFO] | | | \- javax.activation:activation:jar:1.1:compile
| [INFO] | | \- com.sun.xml.bind:jaxb-impl:jar:2.1.7:compile
| [INFO] | +- uk.co.thebadgerset:catalogue:ejb:0.3-SNAPSHOT:compile
| [INFO] | | +- uk.co.thebadgerset:locator:jar:0.3-SNAPSHOT:compile
| [INFO] | | +- uk.co.thebadgerset:catalogue-model:jar:0.3-SNAPSHOT:compile
| [INFO] | | +- uk.co.thebadgerset:index-ra-client:jar:0.3-SNAPSHOT:compile
| [INFO] | | \- org.hibernate:hibernate:jar:3.2.6.ga:compile
| [INFO] | | +- net.sf.ehcache:ehcache:jar:1.2.3:compile
| [INFO] | | +- commons-logging:commons-logging:jar:1.0.4:compile
| [INFO] | | +- asm:asm-attrs:jar:1.5.3:compile
| [INFO] | | +- antlr:antlr:jar:2.7.6:compile
| [INFO] | | +- cglib:cglib:jar:2.1_3:compile
| [INFO] | | +- asm:asm:jar:1.5.3:compile
| [INFO] | | \- commons-collections:commons-collections:jar:2.1.1:compile
| [INFO] | +- uk.co.thebadgerset:index:jar:0.3-SNAPSHOT:compile
| [INFO] | \- uk.co.thebadgerset:aima:jar:0.3-SNAPSHOT:compile
| [INFO] +- uk.co.thebadgerset:thecookerybook-backend:jar:config:0.3-SNAPSHOT:compile
| [INFO] \- uk.co.thebadgerset:thecookerybook-web:war:0.3-SNAPSHOT:compile
|
I'm confused by the class cast exception because I now expect that there should be only one copy of 'com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate' and 'javax.transaction.TransactionManager' on the classpath and that the former does indeed extend the latter. Is this happening because I have included the Hibernate jars in my .ear file instead of using the container supplied version?
Any help is appreciated, thanks.
Rupert
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242357#4242357
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242357
17 years