[Design of JBoss jBPM] - Re: oryx and jbpm
by tom.baeyens@jboss.com
"eikish" wrote : Hi, I'm that "Eiki" :)
|
Hi Eirikur, nice to meet you with your real name :-)
"eikish" wrote : It seems that developers are mostly creating visual XForms syntax editors but not form editors that use XForms underneath if you know what I mean....
|
i don't and i would like to know. can you explain that a bit more ?
"eikish" wrote : I think with Oryx this strategy would be best as well but I'm worried about backward compatability. We are using jBPM 3.3 and don't see that v.4 will be out any time soon so I need to make sure we build (or you as well?) a jpdl extension to oryx that will work on jBPM 3.3 as well...
|
| Will JPDL4 work on 3.3?
|
we aim to supply migration support including a tool for translating jbpm 3 processes to jpdl 4.
jbpm 4 will not be backwards compatible with jbpm 3. though the basic structure would be the same. if you have the jpdl 3 plugin, it should not take a big effort to port it to 4.
if you're willing to lead it, we'ld like to host and maintain the oryx extension to import/export oryx to jpdl 4. we can help with setting up the module in our codebase.
what kind of dependencies are involved in creating an oryx extension ? is that development maven based ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210841#4210841
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210841
17 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - DeliveryCount & ACKs (Repost)
by clebert.suconic@jboss.com
I have been working with https://jira.jboss.org/jira/browse/JBMESSAGING-1294, and this is the current scenario:
- The MessageReference.deliveryCount is only updated after ACKs.
Say, if you:
- received a message
- called message.acknowledge
- called rollback
When you receive that same message again, the deliveryCounter will be incremented, as the ACK will have it incremented:
| Class: ServerConsumerImpl
| {
| ...
| Method acknowledge(final boolean autoCommitAcks, final Transaction tx, final long messageID)
| {
| ...
| if (autoCommitAcks)
| {
| ref.getQueue().acknowledge(ref);
| }
| else
| {
| ref.getQueue().acknowledge(tx, ref);
|
| // Del count is not actually updated in storage unless it's
| // cancelled
| ref.incrementDeliveryCount();
| }
| }
|
If you are using AUTO_ACK (In JMS Terms that means non-transacted), that means you won't ever need to increment the DeliveryCount, as the message will be committed as soon as you called ack.
However if you are using MessageListener, that's not true. If you receive a message and an exception was thrown, the counter should be incremented also. But the ClientConsumer can't call ACK, as that would remove it from the Queue.
So, that means that Acknowledge requires a different semantic when an exception is caught on JMSMessageListenerWrapper.
One way to fix this, would be to change the ACK call signature on ClientSessionInternal:
| void acknowledge(long consumerID, long messageID) throws MessagingException; // Maybe I would leave this
|
| void acknowledge(long consumerID, long messageID, boolean autoACK) throws MessagingException;
|
And have the JMSMessageListenerWrapper doing:
| catch (RuntimeException e)
| {
| if (!transactedOrClientAck)
| {
| try
| {
|
| consumer.acknowledge(jbm.getCoreMessage(), false);
|
| session.getCoreSession().rollback();
|
| session.setRecoverCalled(true);
| }
| catch (Exception e2)
| {
| log.error("Failed to recover session", e2);
| }
| }
| }
|
With that, the AutoACK property would aways be sent on SessionAcknowledgeMessage, leaving the AutoACK to be controlled from the client.
(I could extend the packet if the boolean is considered a problem, & if this solution is acceptable).
The only problem I found on this solution, is requiring a type-cast to ClientConsumerInternal on JBossMessageConsumer.
Any thoughts?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210836#4210836
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210836
17 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - DeliveryCount & ACKs
by clebert.suconic@jboss.com
I have been working with https://jira.jboss.org/jira/browse/JBMESSAGING-1294, and this is the current scenario:
- The MessageReference.deliveryCount is only updated after ACKs.
Say, if you:
- received a message
- called message.acknowledge
- called rollback
When you receive that same message again, the deliveryCounter will be incremented, as the ACK will have it incremented:
| Class: ServerConsumerImpl
| {
| ...
| Method acknowledge(final boolean autoCommitAcks, final Transaction tx, final long messageID)
| {
| ...
| if (autoCommitAcks)
| {
| ref.getQueue().acknowledge(ref);
| }
| else
| {
| ref.getQueue().acknowledge(tx, ref);
|
| // Del count is not actually updated in storage unless it's
| // cancelled
| ref.incrementDeliveryCount();
| }
| }
|
If you are using AUTO_ACK (In JMS Terms that means non-transacted), that means you won't ever need to increment the DeliveryCount, as you will receive as soon as the message hit the client.
However if you are using MessageListener, that shouldn't be true. If you receive a message and an exception was thrown, the counter should be incremented also. But the ClientConsumer can't call ACK, as that would remove it from the Queue.
So, that means that Acknowledge requires a different semantic when an exception is caught on JMSMessageListenerWrapper.
One way to fix this, would be to change the ACK call signature on ClientSessionInternal:
| void acknowledge(long consumerID, long messageID) throws MessagingException; // Maybe I would leave this
|
| void acknowledge(long consumerID, long messageID, boolean autoACK) throws MessagingException;
|
And have the JMSMessageListenerWrapper doing:
| catch (RuntimeException e)
| {
| if (!transactedOrClientAck)
| {
| try
| {
|
| consumer.acknowledge(jbm.getCoreMessage(), false);
|
| session.getCoreSession().rollback();
|
| session.setRecoverCalled(true);
| }
| catch (Exception e2)
| {
| log.error("Failed to recover session", e2);
| }
| }
| }
|
With that, the AutoACK property would aways be sent on SessionAcknowledgeMessage, leaving the AutoACK to be controlled from the client.
(I could extend the packet if the boolean is considered a problem, & if this solution is acceptable).
The only problem I found on this solution, is requiring a type-cast to ClientConsumerInternal on JBossMessageConsumer.
Any thoughts?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210836#4210836
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210836
17 years, 1 month