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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Good article on consistent hashing

by timfox

http://hnr.dnsalias.net/wordpress/2009/02/consensus-protocols-paxos/ View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241161#4241161 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241161

14 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: GetOutcomes returns additional transition

by kukeltje

I remember a discussion about the behaviour that should be there when there is only one transition and whether it should have a required name. afair (can't find the discussion now) a name was not made compulsory so in the outcomes list there would be nothing then. So maybe there should have been a check that *only* if the processing of other outcomes returns no entries, this one should be there as the only one. So it might be a bug since I cannot imagine the this should be filtered out on the 'client' side of the taskservice. Please file a jira issue for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241159#4241159 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241159

14 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Good article on consistent hashing

by timfox

Another good article. At this point I'm thinking we need multi-paxos, which is basically the simplest variant, since we have redundancy built in with our backup servers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241158#4241158 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241158

14 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Filtering non-EJB3 deployments in the EJB3 deployer

by wolfc

Which means that this piece of logic should be on one common ground. Maybe an EJB3DeployerHelper? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241146#4241146 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241146

14 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Possible problem with bean-deployer_2_0.xsd

by Wolfgang Knauf

The validation error is also in JIRA as part of https://jira.jboss.org/jira/browse/JBMICROCONT-446 Wolfgang View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241128#4241128 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241128

14 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Good article on consistent hashing

by ataylor

anonymous wrote : That's not the case. Each node knows about every consumer on every other node, including it's selector. By default JBM will never route messages to a node which doesn't have matching consumers. What i mean is that the remote consumer isn't chosen by the local node. The message is just forwarded to the remote queue and it makes the decision. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241124#4241124 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241124

14 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - message selectors optimization and message grouping

by jmesnil

Working on https://jira.jboss.org/jira/browse/JBMESSAGING-1505 about delivery optimization for consumers with selectors. The idea of the optimization is to provide to consumers with selectors their own iterators on the queue so that they don't have to rescan the whole queue to find messages which they can handle (when the filter match the message) This means that: - consumers with filters have an associated iterator that is used when the queue deliver messages - consumers without filters will peek the messages from the queue In order to distinguish between the 2 types of consumers, we need to peek the consumer which will handle the message from the distributor. I added a peekConsumer() to the Distributor interface to be able to do that. This works fine for RoundRobinDistributor but it is broken for GroupingRoundRobinDistributor (in that case, it must know the message to determine which consumer will handle it). As message groups and queues with selectors are not compatible, there are several options: 1/ forbids to use consumers with filters on a queue with message groups 2/ degrades the delivery algorithm in case of message groups with consumers with filters. In that case, the current algorithm is used (with a full scan of the queue for each call to deliver) (+ warning log) I think (2) is a better option: this will give us the optimization in the most common case and handles the anti pattern case with a degradation of performance. The only real con is that this means we maintain 2 delivery algorithm: - an optimized one (round robin distribution) - an degraded one (messages groups distribution + consumers with filters) depending on the distribution policy type, when QueueImpl.deliver() is called we either use the deliverWithFullScan() (aka the current deliver algorithm) in the grouping distribution case or deliverWithIterators() in the round robin case Some remarks on the new optimized algorithm: * when a consumer with filter has finished iterating on the queue, I reassigned to it a new messageReferences.iterator() so that it can handle new messages. However this means it will iterate again on all the messages it has already discarded to reach the new messages * in the case of consumers without filters, I peek directly from the messageReferences list to deliver. There is no need to have an iterator to share between all the consumers without filters View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241119#4241119 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241119

14 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Job execution fails on JBoss 5.0.0.GA

by tom.baeyens＠jboss.com

https://jira.jboss.org/jira/browse/JBPM-2368 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241118#4241118 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241118

14 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Good article on consistent hashing

by timfox

"ataylor" wrote : anonymous wrote : | | When you talk about queues on each node I guess you really mean *consumers*. | | | | E.g. "If there are remote queues and we haven't yet bound to any queue...", should be "If there are remote consumers and we haven't yet bound to any consumer..." | | from what i understand on how clustering works we initially route the message in BindingsImpl and only know about remote queues not what consumers are on them | | That's not the case. Each node knows about every consumer on every other node, including it's selector. By default JBM will never route messages to a node which doesn't have matching consumers. You can turn that behaviour off by setting routeWhenNoConsumers = true in the cluster config (see docs). anonymous wrote : | | which variant do you think is similar? I don't know, but I know Paxos has been studied over many years by many computer scientists, so I'd be sceptical whether our requirements are satisfied by a completely different algorithm. Most likely your algorithm is already one of the variants or your algorithm doesn't satisfy one of our requirements fully. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241117#4241117 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241117

14 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Good article on consistent hashing

by ataylor

anonymous wrote : | When you talk about queues on each node I guess you really mean *consumers*. | | E.g. "If there are remote queues and we haven't yet bound to any queue...", should be "If there are remote consumers and we haven't yet bound to any consumer..." from what i understand on how clustering works we initially route the message in BindingsImpl and only know about remote queues not what consumers are on them only that there are some. once the message is routed to that queue normal grouping will take over and pin it to a particular consumers. If I have misunderstood how this works can you explain. anonymous wrote : Secondly, your algorithm looks kind of similar to one of the Paxos variants. What's the reasoning why none of the Paxos variants are sufficient for our use case? which variant do you think is similar? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241116#4241116 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241116

14 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009