[JBoss Messaging] - Closing Consumer Causes Hang
by toddjtidwell
So I've run into an odd problem the last couple of days. I've been through my code and I've re-installed JBoss and Messaging several times to try and eliminate it. I can't find a solid cause.
Here's what's happening: We have a non-durable consumer that is listening to a topic. When it receives a messages with a specific int property, it knows it's supposed to stop listening and shut itself down.
It establishes it's connections at follows:
| InitialContext initialContext=new InitialContext();
|
| ConnectionFactory connectionFactory = (ConnectionFactory) initialContext.lookup("XAConnectionFactory");
|
| Connection connection=connectionFactory.createConnection();
|
| Session session=connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
|
| Destination destination=(Destination) initialContext.lookup("OurTopic");
|
| Consumer consumer=consumer=session.createConsumer(destination, "selectorProp = 1");
|
| consumer.setMessageListener(this);
|
| connection.start();
|
Then for the onMessage method we have
| public void onMessage(Message message)
| {
| try
| {
|
| message.acknowledge();
|
| Integer closeProp=message.getIntProperty("closeProp");
|
| if (closeProp == -1)
| {
| try { connection.stop(); } catch (Exception e) {}
| try { consumer.close(); } catch (Exception e) {}
| try { session.close(); } catch (Exception e) {}
| try { connection.close(); } catch (Exception e) {}
| }
| }
| catch (JMSException e)
| {
| e.printStackTrace(System.err);
| }
| }
|
Now, here's the odd thing: It just hangs on the consumer.close() (in bold) call. This used to work. I'm not sure what's changed, I've gone back over it 50 times now and can't find anyhting I changed that would have broken it.
I've found that if I close everything from outside the onMessage method from another thread (like a timer thread or something that just watches the state of the consumer) it works fine. It's just when I close it all down in onMessage.
Is this frowned upon or should this work? Any thoughts on what might be causing it to lock?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970442#3970442
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970442
19 years, 7 months
[Clustering/JBoss] - Clustering Quartz-ra.rar
by kvbisme
I am running a clustered environment and need cron like functionality for some periodic maintenance we perform. The examples in the EJB3 tutorial for using the quartz-ra.rar work picture perfect. That is until I actually cluster the machine up. Then instead of one job executing for the cluster it executes on each instance.
Not a problem I discover the default Quartz implementation uses the Memory Job Store. I add a ?D parameter so that it uses my own quartz.properties file which switches to a JDBC based Job Store.
Next problem, the data sources don?t load before the .rar files so I have to move the file to the deploy.last directory. Now my resource name is deploy.last#quartz-ra ? inconvenient, but still workable.
Now the real problem. The JobStoreCMT file checks to make sure that if the JobDetail is marked as ?volatile? the corresponding Trigger is also marked as ?volatile.? But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to ?true? during construction, but the CronTrigger doesn?t supply that option at construction and the default setting is to have the volatility set to ?false,? which is never changed. A mismatch and a problem for me.
So why isn?t there a volatile entry in the QuartzActivationSpec so we can set this in the deployment, or at least have both Trigger and JobDetail match? I am assuming this is a bug, but JIRA said to start here first. So here I am.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970440#3970440
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970440
19 years, 7 months
[JBoss Seam] - Re: Problem: Custom validate methods in EJBs crash
by bfo81
"gavin.king(a)jboss.com" wrote : There is one problem with performing validation during the action phase: if you are using an extended persistence context, you would prefer to do validation before applying values onto the model object. But by the time we get to the action method, the values have already been applied. It is then difficult to roll back the change to prevent them being written to the database.
|
| However, there is a solution: if you use an extended persistence context with manual flushing, you are fine. There is better support for this in CVS.
Here's another way, which works already now without having to wait for Seam 1.1 or using the CVS version;).
|
| import javax.ejb.SessionContext;
|
| @Resource
| SessionContext ejbCtx;
|
| public String actionMethod() {
| ...
| if (validationFailed)
| ejbCtx.setRollbackOnly();
| ...
| }
By the way: To prevent the Extended Persistence Context from auto-flushing where you maybe do not expect it, annotate your class with @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) so that no storing will be performed. And to make your save-method work again, annotate it with @TransactionAttribute(TransactionAttributeType.REQUIRED)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970438#3970438
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970438
19 years, 7 months