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

[Design the new POJO MicroContainer] - Re: Parallel deployments

by kabir.khan＠jboss.com

I have commited what I have so far, including tests using byteman. I have only implemented the installs asynchronously, uninstalls are still handled the old way. I don't think uninstall is as important, but please chip in if you think I am wrong. Before closing JBKERNEL-25 I will try this out in AS. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241523#4241523 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241523

16 years, 5 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Contents of jnp-service.url file

by ips

We definitely don't want a), since connecting to the loopback address is probably going to provide a faster connection than an external address (though I guess that depends on how the OS does things). As Charles said, b) works for us for the Jopr Agent's use case, but if you think c) is a better solution for other potential use cases (e.g. a remote client reading the jnp-service.url file via NFS and needing a non-loopback address), then we can work with that too. If you do c), the Jopr Agent would basically have to do the same logic you would have done to derive b) from c). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241519#4241519 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241519

16 years, 5 months

1
0
0 / 0

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

by timfox

A result of this also is that you only need a peek() method on the distributor, you don't need a distribute() method at all. Once the queue has the consumer from the peek call it can just call handle() on it directly. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241515#4241515 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241515

16 years, 5 months

1
0
0 / 0

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

by timfox

Actually I think there is a solution to this problem which allows grouping and filters to work together, but it requires a rethink of the way message grouping is currently implemented. The problem is, as already stated, that, with the way the grouping round robin distributor currently works, the message would need to be provided at peek() time in order to determine which consumer to choose, but the message is not known at that time. However, in principle it should be possible to implement the behaviour that if a consumer has both a filter and a message group it should only receive messages which match both the filter and the message group, there's nothing impossible about implementing that. To do this, we would have a Distributor that *always round robins* (i.e we don't have a grouping round robin distributor at all). This makes it easy to have a peek() method on it that does not need a message to be passed in. Once the queue has the consumer it looks up the iterator for that consumer (if any) and gets the next message using that iterator. It passes that message to the consumer which either accepts or rejects it depending on its filter and what message group (if any) it is in. The queue then asks the distributor for the next consumer gets the iterator for that consumer and the process repeats. In this implementation its the *consumer* that would know what message groups it is handling, i.e. the grouping logic moves from the grouping round robin distributor to the server consumer. Each server consumer will only accept a message if both it's filter matches and the message's group id is in the shared set for itself. Every grouping server consumer would need access to a shared map of group id-->consumer. If a consumer receives a message with a group id and no other consumer is already handling it, then it can associate itself to that group id in the map. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241513#4241513 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241513

16 years, 5 months

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Contents of jnp-service.url file

by bstansberry＠jboss.com

I don't think the following should drive this decision, but is just an FYI for anyone interested. C is cleaner from a server-side design POV. This URL String ultimately comes from org.jnp.server.Main, which exposes public List getBootstrapURLs() public String getBootstrapURL() (The latter works by picking the first element in the list returned by the former, which is clunky.) It's appropriate this info comes from Main, as it understands what the URL format is. A separate class NamingServiceURLWriter actually writes the file. It (IMHO correctly) knows nothing about the URL format; it just gets a String and knows how to write it to the file. To do a) or b) above, the logic to pick a) or b) from the overall list is either going to have to go in Main, which is a mixing of concerns, or in NamingServiceURLWriter, which forces that class to understand how to parse the URLs. Using c) avoids this kind of problem. Again, not a huge issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241510#4241510 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241510

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New Parameter for Journal cleanup (Repost)

by clebert.suconic＠jboss.com

I have actually written percentual when I wrote on the code. (pfew!... I thought I used the wrong word there also) | | public class Configuration | .... | | int getJournalCompactMinFiles(); | | void setJournalCompactMinFiles(int minFiles); | | int getJournalCompactPercentage(); | | void setJournalCompactPercentage(int percentage); | | ... | | journalCompactMinFiles = getInteger(e, "journal-compact-min-files", journalCompactMinFiles, GE_ZERO); | | journalCompactPercentage = getInteger(e, "journal-compact-percentage", journalCompactPercentage, PERCENTAGE); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241493#4241493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241493

16 years, 5 months

1
0
0 / 0

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

by ataylor

anonymous wrote : As an initial implementation how about we just use a special node as the store as we discussed previously?# +1, I'm on the case View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241498#4241498 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241498

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New Parameter for Journal cleanup

by clebert.suconic＠jboss.com

It is in Portuguese :-) http://dictionary.reverso.net/portuguese-english/percentual I have actually percentual when I wrote on the code. (pfew!... I thought I used the wrong word there also) | | public class Configuration | .... | | int getJournalCompactMinFiles(); | | void setJournalCompactMinFiles(int minFiles); | | int getJournalCompactPercentage(); | | void setJournalCompactPercentage(int percentage); | | ... | | journalCompactMinFiles = getInteger(e, "journal-compact-min-files", journalCompactMinFiles, GE_ZERO); | | journalCompactPercentage = getInteger(e, "journal-compact-percentage", journalCompactPercentage, PERCENTAGE); | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241493#4241493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241493

16 years, 5 months

1
0
0 / 0

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

by timfox

Nice analysis. I concur that implementing Paxos will be non trivial. As an initial implementation how about we just use a special node as the store as we discussed previously? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241492#4241492 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241492

16 years, 5 months

1
0
0 / 0

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

by ataylor

Here's an explanation of the Paxos algorithm and how it fits our scenario. Basic Paxos is a protocol and we use an instance of this protocol to come to some sort of consensus about which node a group id should be bound to. This means that we would create an instance of the protocol for each group id we need a consensus on. The protocol will have proposers and acceptors and is broken up into 2 phases, 'prepare and promise' and 'accept and accepted. In our case each node will be both proposers and acceptors. 1st Phase When a message arrives with a group id set the node receiving the message becomes a proposer. The proposer will send a 'Prepare(N)' message to all the acceptors carrying the queue it proposes to use for the groupid. The N value is a sequence number for that proposer that is unique across the cluster, i.e. each proposer must choose a sequence number from its own disjointed set. This is used when deciding which proposer should take preference, If an acceptor receives a proposal with a sequence number lower than one it has already receives then it declines that proposal, if it is the highest then the acceptor will return a 'promise' that it will not receive any proposals with a lower sequence number, the 'promise' also contains any previously chosen proposals (queues). The proposer with the highest sequence number we refer to as the leader. A promise will contain the sequence number promised, plus all other sequence numbers promised until that point. At this point we move into phase 2 where the value is committed, i.e. chosen. But before i do you may have spotted an issue. If the leader suddenly fails then we are stuck waiting for a value to be chosen. Because of this it is possible for a proposer after failing to re propose with a higher sequence number (it knows the current highest sequence number as it was returned via the previous declined proposal). This however can lead to a situation where a consensus may have duelling proposers, i.e. p1 proposes with seq1, p2 with seq2, p1 with seq3 and so on. Typically for this you make 1 proposer back off before retrying to give another proposer the time to commit. 2nd phase At this point any proposers that have received a majority of promises back from the acceptors can choose a value and commit it by sending an accept message. Note that because proposals may be received by different acceptors in different orders this could happen. The accept contains the proposers sequence number and the value chosen. The acceptor will accept if the value chosen is the same as received in the initial proposal and the sequence number is the highest agrred to and send an 'accepted' message to the proposer. If a proposer receives enough accepts to a commit then it deems the value chosen. If it doesn't then the proposer can start again. There are also 'learners' that basically are just notified of any values chosen. A client would normally create a proposer but receive the value as a learner. we may not need to do this, alternatively we could just receive chosen values back when a proposal fails. Multi Paxos This is a variant of Paxos. basically the same instance is used for all consensus decisions, an extra param is sent round containing the instance of the protocol (the groupid we are deciding on). This means that you only need to send a prepare message on the first round. Once a leader is chosen the prepare stage is not needed and you cut down on messages sent. For this to work the leader has to remain stable which typically in our scenarion wouldnt happen, i.e. we want the local node receiving the message always to propose its local queue. however, if we merge the roles of acceptor and proposer the leader will be able to commit on behalf of the initial proposer. i.e. a proposer proposes a new instance of the protocol for a new groupid and sends to all acceptors. The leader will receive this and call accept on its behalf. Using a single node Obviously implementing the above is quite complex. A simple solution that Tim suggested is to assign a specific node as a leader. Basically any other node will always ask the leader to make the decision as to which value to choose, the leader holds all the values in a map for future reference. we could do this via some sort of configuration on the server. thoughts, obviously implementing the latter will be much quicker but less elegant. PS if it hurts your head, try reading the spec :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241458#4241458 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4241458

16 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2009