[Design of Messaging on JBoss (Messaging/JBoss)] - Factors that may affect the ordering of messages and how do
by gaohoward
Help and comments are definitely needed, please!
Below is a sum of factors I found and how should an order group deal with them (by default). Some of the choices the order group impl makes may not be appropriate all the time, and if so, we can make them configurable to suit different needs.
1. Message Priority: messages with higher priorities may jump ahead of the messages with lower ones, even if the lower ones may have been created ahead of the higher ones;
/In Ordering Group/ -- Messages in an ordering group will be ignored of their priorities in the ordering of their delivery.
2. Persistency: Non-persistent messages and persistent ones. They are two seperate categories with respect to ordering. Non persistent messages are not guaranteed to survive a server failure and thus may mess up the ordering group processing.
/In Ordering Group/ -- We may force that all messages in the ordering group to be of PERSISTENT delivery mode.
3. Message redelivery: In case of message redelivery (if required), new messages may be delivered to the Queue the same time as that of redelivery.
/In Ordering Group/ -- the message to be redelivered, if in an ordering group, must block any subsequent messages that are in the same message ordering group.
4. Message Ack Modes -- dup_ok/auto/client, the three ack mode affects the acknowledgement timing but shouldn't change the message ordering group's behavior.
/In Ordering Group/ -- The order group will wait for the acknowledge of the current message before delivering the next one, regardless the ack mode.
5. Message selector -- the filtering of messages causes some messages not selected to drop from the subscribers.
/In Ordering Group/ -- We can forbid using selectors, or we can make the selector process always pass any messages that belong to an ordering group, or we can deem the drop of a unsatisfied message to be an effective acknowledgement of completion. Not sure!!
6. JMS Replyto -- during a ordered delivery, if some messages has reploy to header specified, this will yield another message delivery.
/In Odering Group/ -- We should ignore this case. as long as we get acked from the message delivery, we consider it's completed.
7. Expired/Dead Messages -- if some messages expires or failed to deliver for n times, they will go to the expiryQueue or DLQ. Consumer won't get them. If a dead or expired message drops from the ordering group, the order is broken.
/In Ordering Group/ -- We can treat all members in an ordering group as never expires or never be dead, or we treat expired message and dead message as unfinished until they are fetched from the expiryQueue or DLQ and acked (or the transaction containing those messages are committed or rolled back).
8. Transactions -- transactions makes the messages delivery subject to an atomic operation.
/In Ordering Group/ -- If any message in the ordering group is participates in any active transaction, its delivery won't be treated as completed until the transaction is committed or rolled back.
9. Ordering Scope -- messages can be sent from different sessions, on different connections, or from different client applications to different destinations (queues or topics).
/In Ordering Group/ -- We can guarantee the ordering delivery of a ordering group easily if all the messages in an ordering group are produced(sent) within one same session and all the messsages are targeted at one same destination. Messages from different sessions imply different work threads (which makes the message order depending on thread scheduling) and different transactions (which needs more care for ordering). Messages of an ordering group on different destinations is also hard to handle even if they are from one session.
10. ConnectionConsumer -- This is a special case of message delivery.
/In Ordering Group/ -- If messages of an ordering group is consumed this way, we should also keep the ordering correctly even if the consumer can handle the messages concurrently. But in this case we can't guarantee the messages are all processed by one same Session in the pool.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180925#4180925
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180925
16 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Customers having problems during startup trying to use the j
by jhowell＠redhat.com
This is in relation to https://jira.jboss.org/jira/browse/JBMESSAGING-1274
Problem:
The problem is currently that many customers start their systems(default peer id is 0) and they have a problem. The error message states that there are two peers with node 0 as the peer. They then look up the error and figure out that they either need to set the environment variable or manually adjust the peer id.
But the problem is by the point they get the duplicate peer id message, the database is already hosed. If the peers are started at the same time, they generate channel id's using node 0. So you have two datastores with the same node id and different channel ids. This creates an error condition where you just have to wipe away your database.
This entire thing can be avoided if users could use the old jboss paradigm. In order to start a cluster, just start jboss on different nodes in the same network and they will join. This would require something else as the peer id, other than the default 0.
Possible Solution to this problem:
We could change the peer id to a string field.(db would need changing). So how does the peer id being a string help us here. It helps us because we can then ping something that is naturally occuring in the environment to be that peer id. One thing that comes to mind is bind_address ${bind_address}. The bind address could be used as the peer id, or anything else that is in the environment. But right now there are very few int type things available in the environment. This would also pave the way for a possible future fix to add a programatic peer id designation based on things such as mac address, or other things that will uniquely identify the peer.
Jay:)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180864#4180864
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180864
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"tom.baeyens(a)jboss.com" wrote : "heiko.braun(a)jboss.com" wrote : AFAIK the meeting is about the API and CTS, right?
| |
|
| That is a part of it. The first goal is to synchronize the whole team on the goals and strategy of jBPM 4 so that we're all aiming for the same thing.
|
Yes, the api(s) (and cts) should be the result of this
But regarding the supported languages... xpdl is with bull, as is bpel. They already decided on their own api correct? Mainly for backwards compatibility if i'm correct (and maybe the timing). How much are we going to take those into account?
"tom.baeyens(a)jboss.com" wrote :
|
| "heiko.braun(a)jboss.com" wrote :
| | - ProcessEngine, Process, ProcessDefinition
| | - StartEvent (None, Signal, Message)
| | - Task (None, Send, Receive)
| | - EndEvent (None, Signal, Message)
| | - Gateway (Inclusive, Exclusive, Parallel)
| | - Process, Activity Properties
| | - Process, Activity Assignments
| | - Signal, Message
| | - SequenceFlow
| |
|
| We can compare those concepts to jPDL, see how it is different. If the BPMN concept is different, we can see to what extend we want to support it in the jPDL language.
|
Jeff deLong already did some work. I suggest that that is "verplicht leesvoer" (required reading material) for the meeting. But also the other way around. jPDL might have concepts that do not fit in BPMN. Extending it might be needed then.
I'm currently also looking at the bpmn spec in more detail then I ever did and I more and more come to the conclusing that if we focus on the basic concepts to much, we might have to change the api again if more complex functionality is needed (intermediate events? and the corresponding triggers) but if someone proves me wrong, I'll be the first to admit that
"tom.baeyens(a)jboss.com" wrote :
| "heiko.braun(a)jboss.com" wrote : This however is not married to BPMN it merely borrows terminology. Why?
| | Becasue BPMN terminology is very precise and avoids redundancy.
| |
|
| Existing jBPM/jPDL terminology is even more precise as that is executable. BPMN terminology is only described in words in the spec.
http://www.brsilver.com/wordpress/subscribers-only-2/three-levels-of-proc...
See level 3
"tom.baeyens(a)jboss.com" wrote :
|
| "heiko.braun(a)jboss.com" wrote : Once we agree on how these basic concepts relate to each other
| | (and I hardly believe that we manage to so in 3 days) then we could move on to topics that build upon that:
| |
| | Process dialects
| | - handling multiple process dialects
| | - extending process dialect elements
| | - extending the core engine capabilities
| |
| | Embeddability
| | - transactions
| | - persistence
| | - security
| |
|
| I don't see how we can split the discussion like that.
|
Me neither, can you elaborate?
One thing I have not heard people mention but what is a major issue (imo) is backwards compatibility or processdefinition upgrades etc (do we discuss those as well?).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180833#4180833
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180833
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by camunda
For me, the most important point is really to sync everybody, so that we know in which direction we are heading (with jBPM4, PVM, BPEL, API-Proposal, BPMN, ...).
And I would like to discuss some of the proposals made here. For me, the strength of jBPM is simplicity, but beeing powerful at the same time. A lot of projects I have been in or at least know embed jBPM in their architectures/applications. For me it is crucial to conserve this! Some discussions or proposals in the direction BPMN/API were too abstract and theoretical in my opinion. jBPM has a long history, a bunch of experience and had some nice pragmatical approaches. That should be considered when discussing jBPM 4. There is a reason why the people like jBPM :-)
BPMN is indeed an important notation. But I would see the way to go more in a BPMN -> jPDL or a BPMN -> PVM mapping. The latter may be already close to an Executable BPMN. By the way: Executable BPMN is still heavily under research and not yet usable in practice. Good to keep up to date, but really rely on it completely is not the right track in my eyes. And at least it should be done during a real life project, not developed in the lab! My vote: The core engine should kept a simple state machine as it is now.
And I think these thoughts, where I know we have different opinions on the table ;-), need to be discussed first in the meeting, since that's the basis for everything else!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180817#4180817
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180817
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote : AFAIK the meeting is about the API and CTS, right?
|
That is a part of it. The first goal is to synchronize the whole team on the goals and strategy of jBPM 4 so that we're all aiming for the same thing.
"heiko.braun(a)jboss.com" wrote :
| - ProcessEngine, Process, ProcessDefinition
| - StartEvent (None, Signal, Message)
| - Task (None, Send, Receive)
| - EndEvent (None, Signal, Message)
| - Gateway (Inclusive, Exclusive, Parallel)
| - Process, Activity Properties
| - Process, Activity Assignments
| - Signal, Message
| - SequenceFlow
|
We can compare those concepts to jPDL, see how it is different. If the BPMN concept is different, we can see to what extend we want to support it in the jPDL language.
"heiko.braun(a)jboss.com" wrote : This however is not married to BPMN it merely borrows terminology. Why?
| Becasue BPMN terminology is very precise and avoids redundancy.
|
Existing jBPM/jPDL terminology is even more precise as that is executable. BPMN terminology is only described in words in the spec.
"heiko.braun(a)jboss.com" wrote : All of these items do have associated semantics and it should be our first task to make sure everyone has same understanding of what this actually means.
|
The whole team already knows the exact semantics of jPDL. We should go over the BPMN concepts and see how we want to support this in jPDL.
"heiko.braun(a)jboss.com" wrote : Starting off with the jbpm4 code base and API doesn't work because a successful discussion with all participants requires a certain level of abstraction.
|
i don't get this argument.
"heiko.braun(a)jboss.com" wrote : We need to talk about what should be there instead of what is possible with the current implementation.
|
agreed!
"heiko.braun(a)jboss.com" wrote : Once we agree on how these basic concepts relate to each other
| (and I hardly believe that we manage to so in 3 days) then we could move on to topics that build upon that:
|
| Process dialects
| - handling multiple process dialects
| - extending process dialect elements
| - extending the core engine capabilities
|
| Embeddability
| - transactions
| - persistence
| - security
|
I don't see how we can split the discussion like that.
I realize that for us, jBPM 3 to jBPM 4 is in incremental change, whereas for you and Thomas it is a lot of concepts and design decisions in one package. Every decision can be challenged. Even the decisions that potentially take away our foundations and cause us to review all the design decisions again. So far I have seen a lot of new and good ideas, but none of those challenge the basic fundamentals of the approach we took.
So starting jBPM 4 development from scratch is something that I do not consider opportune. This can, of course, change when our approach is challenged (technically, conceptually or in any other way).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180793#4180793
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180793
16 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Adding Ordering Group Features in JBM 1.4
by timfox
I am a bit worried why you don't understand why it is wrong to tag a release that includes a README from a previous release and old documentation.
The README and docs must be accurate for each release. Period. As I've already said, people do read these, even for CP releases. Can you imagine how confusing it is for a user who takes the CP release and follows the instructions and ends up using the wrong remoting version, and nothing works? And then we have to deal with that on the forums?
And yes, community users DO use CP releases too - these are publicly avaikable in SVN, and they DO install them into JBoss AS.
It only takes 5 mins to update the docs and readme.
Hopefully next time you won't forget.
But from now on, please clear with me before tagging any release.
BTW this is not a new process. This is the way we have always done it.
It's fundamental that the README for a release is the actual README for the release, not some other random version.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180791#4180791
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180791
16 years, 3 months