[Design of JBoss jBPM] - Re: meeting context
by heiko.braun＠jboss.com
anonymous wrote :
| ... can you elaborate?
|
Let's take a different angle: This is not about the process definition language. (It's going to be pluggable anyway, right?)
Building an API doesn't necessarily mean throwing away what's there, it could as well mean refactoring the existing one.
The API will have core elements and terminology. Each core elements has associated semantics which lead to implementation detail. We want the API to be correct, easy to use and easy to learn.
The process of finding these core elements (or core concepts) and establishing names for them is important to get one step closer to 'correctness'.
The well known list of 'basic concepts', which Thomas suggested, is merely a collection of core elements that will lead to both a meaningful set of API that can represent of large number of use cases to begin with, but at the same time covers critical areas of the engine implementation. At least that's the idea. If the list is incomplete or the terminology is somehow misleading then make suggestions how it could be changed.
Again this doesn't necessarily mean we ditch the existing jBPM4 code base, it's merely a process of verification.
If the current code base would already have a precise and 'to the point' API, then we wouldn't need to do it.
Here's how I can picture the meeting:
We go through the list of core elements and for each of those we'll first discuss correctness and importance of that element in a BPM world and then secondly match it with jBPM4 elements. Either the BPMN expression is wrong to begin with or unnecessary for jBPM4 (no use case) then we can ditch it right away. But if it turns out to be important then it will either have a representation in jBPM4, just differently named or it requires changes to the code base.
But we'll start with a small set, and then gradually increase to the API until it is feature complete. In the beginning, the API would allow you todo everything jBPM4 is currently capable of, but sooner or later it will.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180960#4180960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180960
16 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Ordering Group enhancement in JBM14 -- Basic impl idea
by gaohoward
Again, any comments will be greatly appreciated. :)
Basic impl idea is we treat the ordering group messages as one container message, when such a message is added to a queue, it will be added in the memory message list (PriorityLinkedList). The difference is, rather than occupies a normal entry in the list, it will be added into its containing OrderingGroup (which looks like just a normal entry in the PriorityLinkedList). During the delivery time, all OrderingGroup entries in the List will be handled specially by handleOrderingGroup() method of RoundRobinDistributor. Details below:
Tasks defined for jbm ordering group
Note: We'll first implement the programming model for the feature and then consider the configuration stuff.
1 - JBossMessageProducer changes
Add:
public void enableOrderingGroup(String ogrpName) throws JMSException
public void disableOrderingGroup();
Modify:
sending methods -- if ordering group enabled, add two properties to message
JBM_ORDERING_GROUP_ID -- either user specified or auto-generated
JBM_ORDERING_GROUP_SEQ -- a long value indicate the order they are produced.
Validations on messages to be sent may be done here to see if the message's header or properties is valid for an ordering group.
2 - session wide help methods
Add:
public String genOrderingGroupID();
-- generate unique group ids for ordering group (maybe reuse existing uuid util in jbm, enough to be session wide unique)
public long getGroupSequenceNum();
-- generate message processing sequence number.
3 - OrderingGroup class - a special message that contains messages belonging to a group
Add:
//just as a message with normal message priority
public class OrderingGroup extends MessageReference
{
private:
String groupID;
List orderedMessages; //or maybe a class to manage it.
public:
MessageReference nextRef(); //this method will wait for the completion of the current one.
}
//RoundRobinDistributor::handleOrderingGroup()
//this methold guarantees the ordered delivery for a message ordering group.
//the main logic will go here
public Delivery handleOrderingGroup(DeliveryObserver observer, OrderingGroup ref, Transaction tx)
Change:
BasicPriorityLinkedList class
enable the list to allow ordering group to be added as one prioritized object. After change, the list should be like:
M1, M2, ... Mn{Mg1, Mg2, ...}, Mn+1
where Mn{...} represents a OrderingGroup object, while other Ms represents a normal MessageReference
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180947#4180947
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180947
16 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Factors that may affect the ordering of messages and how
by timfox
"gaohoward" wrote : 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.
|
We can support priority within the ordering group, just not a total priority order in the queue
anonymous wrote :
| 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.
|
I don't think there is any need to force. If a user uses a non persistent message they do so with the understanding this does not survive restart
anonymous wrote :
| 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.
|
ok
anonymous wrote :
| 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.
|
How would this work with transactions? In JBM 1.4 deliveries in a tx aren't acked until commit
anonymous wrote :
| 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!!
|
If users use a selector with an ordering group, they do so with the understanding that some messages may be missing. Order is still correct but it contains "holes".
anonymous wrote :
| 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.
|
I don't understand the issue here
anonymous wrote :
| 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).
|
No need for special treatment here.
anonymous wrote :
| 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.
|
How do you cope with starvation? If only one message is delivered at a time
anonymous wrote :
| 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.
|
ok
anonymous wrote :
| 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.
|
The user will have to set session pool to 1
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180944#4180944
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180944
16 years, 3 months
[Design of EJB 3.0] - Non-deterministic Default JNDI Name
by ALRubinger
Assume:
@Stateless
| @Remote(MultipleRemoteBindingsTest.class)
| @RemoteBindings(
| {@RemoteBinding(jndiBinding = MultipleRemoteBindingsTest.JNDI_BINDING_1),
| @RemoteBinding(jndiBinding = MultipleRemoteBindingsTest.JNDI_BINDING_2)})
| public class MultipleRemoteBindingsTestBean{}
The JNDI Name for this bean is non-deterministic, as there's nothing to signal a true default.
JBossSessionBeanMetaData smd = ...; // This is decorated
| String jndiName = smd.getJndiName();
At the moment it's JBossSessionPolicyDecorator that chooses the first populated @RemoteBinding.jndiBinding to be default:
@Override
| public String getMappedName()
| {
| // Obtain remote bindings
| List<RemoteBindingMetaData> bindings = this.delegate.getRemoteBindings();
|
| // If defined, use the first remote binding as a JNDI default
| if (bindings != null && bindings.size() > 0)
| {
| String jndiName = bindings.get(0).getJndiName();
| if (jndiName != null && jndiName.length() > 0)
| {
| return jndiName;
| }
| }
|
| ...}
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180929#4180929
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180929
16 years, 3 months