You can't lose messages with DUPS_OK, but there is a possibility of duplicates
if the system fails and recovers.
As Andy says, you can then implement duplicate detection and effectively then
get once and only once delivery.
View the original post :
http://www.jboss.com/index.html?module=bb&op=
Right, I won't, but just possibly losing some messages still better than
risking losing a message *and* possibly getting duplicates (we can afford
losing some messages and then requesting retransmission through a persistent
channel/queue).
|
Or you could make your app idempotent and handle t
"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, but just possibly losing some mess
"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*
anonymous wrote :
| 3. Is producer flow control going to be implemented in JBM 2 ?
|
yes
View the
"vc123" wrote : "ataylor" wrote :
| | I am not sure why the consumer falls behind so quickly. True, the
producer does not do much, but neither does the consumer, and yet it is about
30% slower than the producer which leads to the queue explosion.
| |
|
| Probably the other mes
"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
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 available at the end of March.
"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
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. However, I think that the reason the throughput is
dropping to 0 is because the server has run out of memory, try upping th
"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
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 delivery does.
The
"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
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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=vie
Hypersonic has no transaction support, so should never be used other than very
simple demos.
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128503#4128503
Reply to the post :
http://www.jboss.com/in
"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 reliable which is a vio
"vc123" wrote : 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 e
anonymous wrote : 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 ?
JBossMessaging is very reliable, it is 100% Sun CTS (Compatibility Test Sui
17 matches
Mail list logo
