March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by Kevin.Conner＠jboss.com

Calm down guys, the original question has now been answered from both perspectives. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139411#4139411 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139411

18 years

1
0
0 / 0

[Design of JBoss Profiler] - Re: JBoss Profiler 2

by jesper.pedersen

There will be a GUI based tool when we hit GA. E.g. we are working on it currently :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139409#4139409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139409

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by timfox

In other words make everything idempotent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139406#4139406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139406

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by timfox

"mark.little(a)jboss.com" wrote : "timfox" wrote : Another common situation is that users find using XA too slow to bridge each message from one provider to another, so instead opt for "DUPS_OK" quality of service mode, and then just detect duplicates in their own code at the end. | | You know XA (and transactions in general) are much more than this, right ;-)?! I'm describing a very common pattern where users want an end to end "once and only once" delivery guarantee, but don't want to use XA to accomplish this because of performance issues. E.g. you have a set of queues potentially each one living on a different system. Messages are consumed from one queue, the message is processed then the same or another message is passed to another queue for the next stage of the workflow. If the system crashes at any point we don't ever want to be in a situation where the workflow stops mid way through, i.e. lose messages. The "obvious" way to do this is after processing the message, to acknowledge it from the current queue and send it on to the next queue in a single transaction. If the two queues are on different resource managers this would involve XA. Alternatively you can send the message on to the next queue and acknowledge it from the current queue in separate transactions, but make sure that you send it on *before* you ack it. In case of failure you may end up with the message sent, but not acked. So on recovery the same message might get processed again (i.e. you have duplicates), but you'll never end up losing a message. Then, at the application level, you implement your own duplicate detection. E.g. you discard any messages whose id you have seen before. You can keep a cache of ids of the message you have seen. This of course needs to be persisted. So the end result is a "once and only once" guarantee but without XA. (Assuming an infinite cache - but it's a trade off) Anyway, don't know why you asked the question Mark, you know all this already :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139405#4139405 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139405

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by Kevin.Conner＠jboss.com

"timfox" wrote : Let's avoid a pointless "my component is better than your component" discussion. | | The user can decide what they want to use based on their requirements and the components functionality :) I agree 100% :), the technologies solve different problems and work well together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139401#4139401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139401

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by Kevin.Conner＠jboss.com

"dsmiley" wrote : So, if I'm understanding this correctly, JBoss ESB supports QOS_ONCE_AND_ONLY_ONCE but only if both sides are XAConnectionFactory? If so that's nice... I may be able to work with that. How is this configured (enabled/disabled)? It is handled automatically if running within the context of a transaction and it references the XAConnectionFactory. The JCA adapter already provides this (for JMS) but it is also possible for the scheduled listener/gateway to control the transaction and, from tomorrow, the message aware listeners will support it once again. "dsmiley" wrote : I'd prefer QOS_DUPLICATES_OK for reasons Tim Fox got into. I don't think this should be hard; just wait until the service is done and THEN acknowledge the JMS message from the gateway. It should already be possible to configure the acknowledge mode. I believe Daniel added this functionality so perhaps he can add a comment to this. "dsmiley" wrote : I don't need batching... but Tim gave reasons why that's good too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139400#4139400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139400

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by timfox

"Kevin.Conner(a)jboss.com" wrote : | The ESB also has other cool features not available in bridging :) | If you think I'm trying to compare the bridge to the whole ESB then that's certainly not what I was doing - apologies if that is the impression you have got. That would certainly be an apples-oranges comparison. We were simply bringing to attention a component from JBM which seems to do similar things to a particular component in ESB (the jms router thingy). We've had to deal with a lot of the issues that you probably will have to do deal with, w.r.t reliability guarantees etc, and just thought you might be interested. Let's avoid a pointless "my component is better than your component" discussion. The user can decide what they want to use based on their requirements and the components functionality :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139396#4139396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139396

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by mark.little＠jboss.com

"timfox" wrote : Another common situation is that users find using XA too slow to bridge each message from one provider to another, so instead opt for "DUPS_OK" quality of service mode, and then just detect duplicates in their own code at the end. You know XA (and transactions in general) are much more than this, right ;-)?! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139393#4139393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139393

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by dsmiley

So, if I'm understanding this correctly, JBoss ESB supports QOS_ONCE_AND_ONLY_ONCE but only if both sides are XAConnectionFactory? If so that's nice... I may be able to work with that. How is this configured (enabled/disabled)? I'd prefer QOS_DUPLICATES_OK for reasons Tim Fox got into. I don't think this should be hard; just wait until the service is done and THEN acknowledge the JMS message from the gateway. I don't need batching... but Tim gave reasons why that's good too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139391#4139391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139391

18 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by Kevin.Conner＠jboss.com

"timfox" wrote : So I guess users have a choice - they can use the esb router if it suits their needs, or just use the bridge if they want more flexible QoS settings, batching and reconnection. Not quite how I would put it but I do agree with the choice ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139389#4139389 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139389

18 years

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 March 2008