January 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Redundant cluster configuration property

by jbertram＠redhat.com

I recently discovered that the default value for the "Clustered" attribute of the jboss.messaging:service=PostOffice MBean in all the <JBOSS_HOME>/docs/examples/jms/*-persistence-service.xml files changed from "true" to "false" from JBM 1.4.0.SP3_CP03 to 1.4.0.SP3.CP04 (https://jira.jboss.org/jira/browse/JBMESSAGING-1422). This got me thinking about why there is a "Clustered" attribute for the post-office at all. Would it not be better to programmatically activate post-office clustering based on the presence of a clustered destination in destinations-service.xml? What does a clustered post-office buy you if no destinations are clustered? Also, what happens with a clustered destination if the post-office isn't clustered? These last two questions would be moot if post-office clustering were enabled programmatically. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200185#4200185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200185

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Failover & Paiging...

by clebert.suconic＠jboss.com

This is a summary of what we discussed today at: http://www.antwerkz.com/javabot/javabot/home/3/%23jbossmessaging/2/07/1/0... (starting at [10:41]) The basic problem is when the ACK is replicated to the backup node, the message eventually will be on page file, and replicateACK may fail for not being able to locate the ID on the queue: public void deliverReplicated(final long messageID) throws Exception | { | // It may not be the first in the queue - since there may be multiple producers | // sending to the queue | MessageReference ref = messageQueue.removeReferenceWithID(messageID); | | if (ref == null) | { | throw new IllegalStateException("Cannot find ref when replicating delivery " + messageID); | } | | So fix that, based on our discussion, I'm going to change DuplicateID detection to work at Queue level (not Address), and when ref == null, I'm going to add a new ID to be ignored on the Queue. That will require some synchronization on route when duplicateID != null. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200184#4200184 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200184

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-1457 - Unexistent destinations on both nodes

by clebert.suconic＠jboss.com

Howard, I'm not sure if the current fix is correct. on You should just ignore the Queue.. yes.. but on MessagingPostOfficeImpl::performFailover: } | else | { | //Cannot failover if there is no queue deployed. | | log.warn("Cannot failover " + queue.getName() + " since it does not exist on this node. " + | "You must deploy your clustered destinations on ALL nodes of the cluster"); | } | I don't think deleteBindingFromStorage(queue) should be called. As merge didn't work because of the warning, we need to make sure the data will be received when the failed server starts. //Delete from storage | | //Note we must do this *after* we have done any merge. | //This is because if we did it first, then the merge failed, we'd be left with the old channel deleted | //but the messages would have still be in the old channel | //meaning they would have disappeared from the users point of view and it would involve manual | //database intervention to correct it | //See http://jira.jboss.com/jira/browse/JBMESSAGING-1113 | | deleteBindingFromStorage(queue); | | log.debug(this + " deleted binding for " + queue.getName()); | | // Note we do not need to send an unbind request across the cluster - this is because | // when the node crashes a view change will hit the other nodes and that will cause | // all binding data for that node to be removed anyway. | } | So, you should improve one of the tests to validate the failed queue still have data when everything is restarted, and move the deletebindingFromStorage be called right after merge. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200177#4200177 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200177

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Can't redeploy the transaction manager

by scott.stark＠jboss.org

I don't see why unbind would be much different than rebind. What would be bound in jndi while the tm is undeploying is not likely usable anyway? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200157#4200157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200157

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins

by Kevin.Conner＠jboss.com

"camunda" wrote : Agreed. But in reality in your project, what do think the people do? Build a (complicated) correlation mechanism or hack an action which enables the SIgnalCommand again? ;-) It is our intention to provide some support for this but, as always, there are other issues to be addressed. "camunda" wrote : But you could have to process flows in parallel, both communicating with the ESB or maybe both flows even communicate with an external partner. Only the token id is unambiguous in this case. In the projects I know I always was fine with the token id. But in this case the communication would initially be driven by the jBPM process and, as such, the correlation mechanism would again be relevant. You would still need to handle instances where the token had moved forward and/or looped and the token id is not sufficient for this. "camunda" wrote : BTW: Where is the problem with a loop? That doesn't change anything with the token id. Only Fork/Join does... It doesn't change the token id but it can change the request being made. As such any corresponding responses should be matched up. quote="camunda"]Don't worry ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200131#4200131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200131

17 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Decision time...

by david.lloyd＠jboss.com

One thing I do want to do before the final release - I think that Transporters should be separate from the core. The reason is that I think it is more of a "beta" feature - there are many things that haven't been considered (like remote reference management, distributed GC, etc.) that should be considered before this feature is considered "stable". Also I'd want to find at least one or two users of the feature before releasing Transporters as stable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200130#4200130 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200130

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins

by camunda

Kevin wrote : | It is the correlation functionality that is missing and not the signal command. | Agreed. But in reality in your project, what do think the people do? Build a (complicated) correlation mechanism or hack an action which enables the SIgnalCommand again? ;-) BTW: In pre-ESB projects we often used the token-id only for correlation, in some circumstances this doesn't cause problems. This is a project based decision. But to have the expected state is definitely best practice, I agree. Kevin wrote : | camunda wrote : | | I always work with the token id, because it is unambigous if multiple tokens exist for the ProcessInstance. | | | Except tokens come and go, loop etc. | But you could have to process flows in parallel, both communicating with the ESB or maybe both flows even communicate with an external partner. Only the token id is unambiguous in this case. In the projects I know I always was fine with the token id. BTW: Where is the problem with a loop? That doesn't change anything with the token id. Only Fork/Join does... Kevin wrote : | Thanks very much for the feedback, keep it coming :) | Don't worry ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200125#4200125 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200125

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins

by Kevin.Conner＠jboss.com

"camunda" wrote : But how to implement this if you think of the use case that an external client asks for the status of the process instance? Sorry, I thought I had previously agreed that was a valid use case. "camunda" wrote : You skipped the second question in that sentence ;-) Let's say you handed over the token id as correlation identifier to a third party application. It calls back, e.g. via JMS, containing only the token id. Now you have to signal the process instance with that token id, right Sorry, I thought I had answered this. You cannot do this with just the token id as it is not sufficient for signalling. You need to have a different correlation mechanism with the external service and something has to manage that correlation. "camunda" wrote : And currently this functionality is missing, so this is why I see the demand for the "old" SignalCommand. It is the correlation functionality that is missing and not the signal command. "camunda" wrote : By the way, an often requested use case is to update the version of the ProcessDefinition of a special ProcessInstance (e.g. to apply a fix). This is possible with a Command in jbpm, even if it is marked as experimental, since it can cause some problems. One problem with the currrent implementation is, that node-id has changed, so the EPR isn't working. I added a note in the ChangeProcessInstanceVersionCommand but think we can ignore that for know. If people use that command, they should know what they are doing... This is not something we support with the current integration as there are many ways in which it can go wrong. As you say, it is experimental. "camunda" wrote : I always work with the token id, because it is unambigous if multiple tokens exist for the ProcessInstance. Except tokens come and go, loop etc. "camunda" wrote : Basically I agree with it. I am not complaining about the solution as such, the problem is more the too complicated code and missing examples and the lack of an excellent tutorial for it. And some "details" are missing, like the correlation stuff. All of it "just" a matter of resources and time ;-) I think we agree on all of these :) Thanks very much for the feedback, keep it coming :) Kev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200119#4200119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200119

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ServiceInvoker / deliver in new transaction

by camunda

Hi Mark, I had a look into it again today. I have a problem of correlation now: After delivering asynchronously I have nothing, not even some ESB UUID. So how to wait for exactly this result message in a generic easy way? The second problem: If I solve the correlation by some business identifier I still have to wait for the response of the service, but there is no way on the ServiceInvoker to do something like: | serviceInvoker.waitForResponse(categoryName, serviceName, timeout) | // or with correlation UUID | serviceInvoker.waitForResponse(categoryName, serviceName, uuid, timeout) | // or at least | serviceInvoker.getResponseCourier(categoryName, serviceName) | // or the like | Otherwise I cannot do that in a generic way because I need to subscribe to JMS for example (but then I have to know the special queue name and I am bound to JMS). What do you think? Or am I on the wrong path? Cheers & Thanks Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200113#4200113 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200113

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Can't redeploy the transaction manager

by jhalliday

Yup, that's a bug. The proper fix is to unbind the various JNDI entries on destroy(), but I'm concerned that some services in the app server rely implicitly on the bindings provided by the transaction manager without actually declaring a dependency on it. I have a feeling these will break if I use unbind(). Maybe we just bite the bullet, make the change and clean up the dependencies as needed. Or we could wimp out and use rebind() instead of bind() at create time, which would allow for clean service restart whilst being less disruptive. Any thoughts from the AS side of the house? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200100#4200100 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200100

17 years, 2 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 January 2009