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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"clebert.suconic(a)jboss.com" wrote : | Wouldn't a queue.load take care of this? Maybe I didn't understand your point here. If you have 2 nodes, node A and node B. There exists durable sub S1 on node A for topic T Messages are being sent via node A to topic T. They are routed to node B where they go into S1. node B then fails More messages are now sent to node A, it is a requirement of the JMS spec that S1 still receives the messages sent. If you don't reload S1 until the client requests it, then S1 won't get the message and we have broken the JMS spec. This isn't such an issue when using a shared db since we persist before send, but when doing in memory replication it simply won't work. A similar reasoning applies to queues. We're not permitted to lose any messages destined for a queue while failover is occurring. We must ensure that all messages end up in the queue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980440#3980440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980440

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"clebert.suconic(a)jboss.com" wrote : | | Based on what we talked before, a client connection to a nodeA will always have to faile to a nodeB. A server rule will determine this. | | So it's not totally driven from the client side then? anonymous wrote : | | What we should do then if a connectionState has a non clustered queue on its hierarchy during a connection failure event then? Throw an exception? Disconnect the Consumer? | | I would say disconnect it and any further operations (e.g. receive()) on that consumer should throw an exception. anonymous wrote : | So far I think we could (don't know if we should) reconnect non clustered topics on the new node. We won't be able to guarantee deliveries, but at least we wouldn't interrupt the client. Now if the requirement is to fail over only on ClusteredQueues we should know what to do then. | A non clustered destination is, by definition, non clustered. Therefore there is no expectation of HA for that destination. anonymous wrote : | | I will be able to refactor anything if we get some problem. I'm constructing this piece by piece, we will be able to refactor later. That's cool. I'd just be careful of going too far down the wrong path. Otherwise you may have a *lot* of refactoring to do :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980436#3980436 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980436

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

"Tim" wrote : There are other issues here. When a durable subscription is attached to a topic, then the subscription must retain all messages *even if it isn't active* - this is a requirement of the JMS spec Wouldn't a queue.load take care of this? Maybe I didn't understand your point here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980435#3980435 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980435

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

"Tim" wrote : How can you ensure that different clients that use the same queue fail over on to the same node? Based on what we talked before, a client connection to a nodeA will always have to faile to a nodeB. A server rule will determine this. "Tim" wrote : Non clustered queues don't need to be reconnected. If queues want to benefit from HA then they should be made clustered. What we should do then if a connectionState has a non clustered queue on its hierarchy during a connection failure event then? Throw an exception? Disconnect the Consumer? So far I think we could (don't know if we should) reconnect non clustered topics on the new node. We won't be able to guarantee deliveries, but at least we wouldn't interrupt the client. Now if the requirement is to fail over only on ClusteredQueues we should know what to do then. "Tim" wrote : Personally I don't think you can drive the failover fully from the client side. I will be able to refactor anything if we get some problem. I'm constructing this piece by piece, we will be able to refactor later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980431#3980431 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980431

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: VirtualFile.toURL() returning vfsfile:

by scott.stark＠jboss.org

Some do cache children (jars). Why can't the existing close be used to releases resources? Unless as part of profiling there is a reason to refresh a deployment dir/top-level deployment its something that I don't know we want to support. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980423#3980423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980423

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Design of a Content Based Routing Service

by kurt.stam＠jboss.com

I've been looking at the donated cbr code (see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=86937, thx for that btw :)) and I think that for us to use it we need to make the following changes: 1. Technology: a. upgrade to the latest JBossRules (3.x) b. move towards the new java-like rules definition c. move to a plain java implementation 2. Integration a. Name the CBR as an action and define a processor for it, or in the architecture to come, define the CBR as a Service and register it's ServiceBinding in the Registry b. Add the CBR action as a (routing) action in the action chain. 3. Questions a. Should the CBR service return a service/action name, or should it actually forward the message straight to it. b. Do we support routing to one or multiple destinations for the next release? c. Our messages are either of type Serializable or XML, will we support the content based routing of both types (or just XML)? d. What happens when no rules match? Do we have to create a 'catch all' rule, or is it ok to return 'sorry'. What will happen next? Will the message simply go to the next action? Dave I'd love to hear your, or anyone elses, thoughts on any of this. --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980422#3980422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980422

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"clebert.suconic(a)jboss.com" wrote : | I'm doing the failover from client side. The client will detect the socket failure and it will open a new connection on a new server, when the connection is opened the original nodeID is also sent then the queue from the old server is made active on the current server. | How can you ensure that different clients that use the same queue fail over on to the same node? There are other issues here. When a durable subscription is attached to a topic, then the subscription must retain all messages *even if it isn't active* - this is a requirement of the JMS spec. If you only load the durable sub when requested to by a client, then you're going to lose when doing in memory persistent replication. A similar reasonsing applies to queues. anonymous wrote : | At this point I'm having to deal with PostOffice interface as well because in a failover event, non clustered queues will be reconnected as well. Non clustered queues don't need to be reconnected. If queues want to benefit from HA then they should be made clustered. Personally I don't think you can drive the failover fully from the client side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980416#3980416 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980416

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Table object_snap uses Oracle keyword UID

by daniel.brum＠jboss.com

Jeff - thanks for this note, I am using the same column name in the new Message Store service. I will change this before we release it. As for fixing this in the Beta/MP1 release, it will require some code changes to the DAOs used by the ObjStore EJB(s). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980415#3980415 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980415

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

"Tim Fox" wrote : I don't understand why you need a new method on the post office (the bind with the node id), can you shed some light....? | | On failover, it's the post office that will detect the failure using JGroups, so it will know what has failed over. I'm doing the failover from client side. The client will detect the socket failure and it will open a new connection on a new server, when the connection is opened the original nodeID is also sent then the queue from the old server is made active on the current server. "Tim Fox" wrote : Therefore all it needs to do, is for each of the remote queue stubs correspsonding to the queues for which it will take over responsiblity it needs to replace them with a local clustered queue and call load() on it. Consider the case where the client also died with the server, for example a MessageDrivenBean located on the save VM as the JMS Server. On that case all we have to do is to wait the client come back alive, we don't need to failover that queue. Why I'm saying that? Because I think it would make sense to fail over as it's needed, having the client taking the action on where to fail over to. I'm just prototyping at this point. At this point I'm having to deal with PostOffice interface as well because in a failover event, non clustered queues will be reconnected as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980408#3980408 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980408

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

I don't understand why you need a new method on the post office (the bind with the node id), can you shed some light....? On failover, it's the post office that will detect the failure using JGroups, so it will know what has failed over. It will also know which queues it needs to take over responsibility for, since it already has this list of queues internally. Therefore all it needs to do, is for each of the remote queue stubs correspsonding to the queues for which it will take over responsiblity it needs to replace them with a local clustered queue and call load() on it. When reconnecting consumers to the failed over queue, I agree you will need to add a ne getBindingForQueueName() method that takes a node id. However this only needs to be on the ClusteredPostOffice interface, not the post office interface. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980402#3980402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980402

19 years, 5 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