October 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by genman

i would like to add, this common case *would* be solved with a client side interceptor. But then again, with HTTP load balancers, etc. you still need to replicate the request ID on all nodes. Anyway, this feature would be relatively easy to write and might prove useful for a few customers. I don't know what JMS provider (if any) support duplicate detection on MessageProducer.send(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977126#3977126 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977126

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by genman

But then, what's the use of tracking on the client side when the client doesn't know the message did arrive successfully? I've had to deal with billable message traffic coming from an SMPP interface. Ultimately, to prevent the system from billing twice, the client had to supply a unique message ID. This ID was tracked in a central database. Something like this could be easily managed by a JBossCache instance, which would manage replication and expiration of old data. It might be only useful to a few users, and only useful if the client didn't have a transaction going. A more common issue than the JMS client reporting error, is that the interface which generates the JMS traffic (such as an SMPP or HTTP interface for instance), fails to send back "success" and the remote system reattempts the same SMPP/HTTP/etc. transaction again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977124#3977124 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977124

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by apwalker

When tracking messages on the server side you really need to consider the amount of memory required when you have large message volumes. Also when clustered you have to replicate this information since the client may re-send the message on another node. It might be a better solution for the client to keep track and only for the life of their session. This could be done with a client side interceptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977098#3977098 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977098

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by genman

Although you suggest 2PC, you could always have the server track the message by ID. If it sees the same message again (and it was successfully sent) then ignore it. I'm pretty sure this is something JBossMQ doesn't do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977097#3977097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977097

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: EAR has to be both parsing and structure deployer?

by scott.stark＠jboss.org

That is correct, the ear deployer is a structure deployer that identifies valid deployments and the classpath. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977087#3977087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977087

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Sundry JBossXB changes

by alex.loubyansky＠jboss.com

All fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977085#3977085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977085

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - EAR has to be both parsing and structure deployer?

by bill.burke＠jboss.com

The structure of an EAR is affected by its metadata, so, I"m assuming that the EAR structure deployer has to parse the application.xml file if it exists. FOr example, if application.xml file is present, then only those modules listed are components, if no application.xml file is present, then all top level things of the ear must be considered as a deployment, EXCEPT the lib/ directory. Also the lib/ directory is a default. application.xml also has metadata that can specify a lib directory within the ear. I'm guessing some thought has been put into this, so would like your opinion. Thanks, Bill View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977079#3977079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977079

19 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0

by reverbel

"mark.little(a)jboss.com" wrote : Oh, and I assume you have to durably record the mapping between the short-hand notation (long) and the real transaction id. Essentially keep a reference as to where your index (the long) has reached so that, upon failure and recovery, you can continue counting from where you left off (or you risk generating a new mapping using the same counter before half a million years is up ;-). This durable recording is going to impose some overhead: every time you increment the counter you have to record it to disk . Plus, it probably needs to be managed transactionally too. Or did I miss something? Very good points. Generating local ids with a linear, one-dimensional transaction counter would have these problems indeed. Fortunately, a high/low approach works well here. Below I describe the one implemented by the old TM code in JBoss AS. (That part of the code is not actually old, BTW. It was written about one year ago). Split the 64-bit counter in two parts: a high part with (say) 20 bits, and a low part with 44 bits. Whenever you need to generate a new local transaction id, you increment just the low part, without durably recording its value. Whenever the TM (re)starts, you increment the high part and durably record its new value. Thus the (durable) high part counts TM restarts and the (non-durable) low part counts transactions in a TM run. With this solution, the overhead per transaction is just the cost of an in-memory increment. The downside, of course, is a significant reduction on the maximum time any given transaction may exist in the current set of transaction log files, but half a million years was too much anyway. :-) Regards, Francisco View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977076#3977076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977076

19 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0

by reverbel

"mark.little(a)jboss.com" wrote : Yes, but in TP systems you never take a chance, no matter how small. Plus, I'm sure someone made a similar comment about date fields back in the 1960's and looks what happened come the year 2000! ;-) Now your argument sounds a bit like a rhetorical one, as the year 2000 issue was an entirely different problem! ;-) Unless you use unbounded transaction ids you will be always taking a chance, which of course should be very, very, very small. Since the XA spec places an upper limit on the size of Xids, there is no way around this in the XA design space. It is really a matter of reaching a point that is safe enough. Half a million years at one million TPS is certainly safe enough. Note that this would not be an upper limit on the entire lifetime of the TP system, but just on the time a transaction may remain in the active state or in a heuristically completed (and not yet forgotten) state. In other words, it is just an upper limit on the time any given transaction may exist in the current set of transaction log files. Half a million years is actually way over the top for that; a few months would probably be enough. I understand "long transactions" are becoming increasingly important, but... Do you really expect them to be that long? ;-) Regards, Francisco View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977073#3977073 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977073

19 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0

by reverbel

"reverbel" wrote : | 60 seconds/min * 60 mins/hr * 24 hrs/day * 365 days/year = 31536000 seconds/year | | 2^64 transactions/wrap * 10^-6 seconds/transaction * 31536000 seconds/year = 584942.41 years/wrap | Ooops, wrong math: 2^64 transactions/wrap * 10^-6 seconds/transaction * (1/31536000) years/second = 584942.41 years/wrap Still, the result was correct. Regards, Francisco View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977071#3977071 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977071

19 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2006