"timfox" wrote : "vc123" wrote :
| |
| | 1. I will, but we do not want DUPS ;)
| |
| |
|
| Well you won't get reliable (once and only) delivery using AUTO_ACKNOWLEDGE
either.
|
| AUTO_ACK = *at most once*
|
|
Right, I won't,
"ataylor" wrote : Can you try running the consumer in DUPS_OK_ACKNOWLEDGE mode?
|
| What is the time scale for shipping your JMS Application, we have JBM 2
being released later this year with improved performance at both the transport
layer and the persistence layer. The Alpha should be avai
"ataylor" wrote : The first thing I notice is that you are setting the
timetolive on send to 1000ms, this means that most of these messages could
expire and never be consumed, set this to 0.
|
Removing timetolive did the trick. Apparently, expiring messages was killing
the GC.
Now, the
"ataylor" wrote : anonymous wrote : But, what about non_persistent messages ?
In the current JM implementation non_persistent delivery performance seems to
be determined by the relational database backend too as I wrote earlier, though
it does not suffer from sync writes as much as persistent de
"timfox" wrote : For persistent messages, you are fundamentally limited by the
speed of your database.
|
| So your persistent message throughput will entirely depend on how your
Oracle box is set-up tuned etc. Oracle is very tunable however.
For persistent messages in the AUTO_ACK mode, yo
"timfox" wrote : "vc123" wrote :
| |
| | anonymous wrote :
| | | On my tests, persistent auto-ack send was too fast ( about 3000 1K
messages/s) which means that there is no auto commit. if so, it would mean
that persistent message delivery is not really
Hi,
We are evaluating JBoss Messaging suitability for reliable delivery.
I am not quite sure how reliable message delivery (PERSISTENT) is implemented
in JBoss Messaging. Assuming a JDBC persistence manager, does the AUTO_ACK
mode result in a JDBC commit after each message ?
On my tests,
