Hello Timfox
With 'workers' i guess i mean consumers. In the jbos.xml i have a config like
this:
<invoker-proxy-binding>
--bla bla
20
20
/-bla bla
meaning i want 20 concurrent consumers (the logging calls them workers) to work
parallel to pick up the messages that are sent to the queue. A nice feature,
but during that process consumers get lazy and do not respond anymore :(. So,
with JBossMQ the only solution is to restart JBoss after about 24 hours.
I presume that any other solution, ie JBoss Messaging, could have the same
problems so a nice feature would be if it would have the ability to recover
from dying consumers. If not, a reset of the messaging system would hlp a lot
because other services would be uneffected by a restart.
Another problem with JBossMQ (most probably) is that JBoss JCA connection pool
is very itchy about not closing database connections. So, when a consumer
stalls, it might keep the connections open indefinitly and this will lead to
terrible other problems. Just do a search on the forums and you will see that a
lot of people who switch to JBoss experience significant problems with JCA.
And in my configuration you see a lot of dead database connections combined
with a decrease in MQ activity.
So, to solve my problem i see a few possible solutions:
1. improve the code that is executed in the consumer (because the consumer
hangs because my code within it hangs)
2. get a MQ system that have some managing capability (to cover up for 1.)
3. drop JBoss JCA, it is simplly too itchy about connection closing (but this
is a different story)
So, basically i my situation i would like to configure the following:
"Dear messaging system. You have to work through thousands of messages per day.
I would like you to process them swiftly, and with accuracy i could expect from
a computer program. But, every now and then you will get an evil message that
might take too much of your attention. Please discard these messages if you
spend more then 10 minutes of your time (or put them in a evil messages group
where a few dedicated consumers handle these nasty cases)." And if a tsunami of
evil messages arrive at your get i understand, so no heart feelings when i want
to restart you without bothering other processes that are running in the
application server!
FYI, a single message in our application will lead to several hundreds http
connections with other servers, serveral thousand database requests, a couple
of external webservices (AXIS, JBoss WS... cool features!) etc. So, a lot of
situations where things can stall or go wrong. To get a feeling, if the
concurrent cosumers are set to 20++, JBoss will die within the hour (only
option "kill -9 PID").
And one other thing. We have a couple of message queues. Some can be considered
'bulk queues', but others are processing financial transactions, so i would
wish to discriminate them (the pigs queue is more equal then others).
In a nutshell:
- messaging managability
- restart, preferably on queue level
- discriminating queues
- recovering of dead consumers, or...
- regrouping slow/fast messages, so the bulk will be processed in time
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978301#3978301
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978301
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
