[Design of Messaging on JBoss (Messaging/JBoss)] - Unnecessarily pulling messages
by timfox
When a channel deliveries messages to a receiver that can only accept x messages, the channel delivers as many messages as it can until the receiver returns null to signify it doesn't want any more.
There is a problem with this in a clustered setup, when pulling messages from a remote queue.
The channel will deliver as many messages it can from the local queue, and then, if the receiver is still ready, in some situations will start pulling
messages from a remote queue.
So what can happen is the local queue pulls a message from the remote queue then offers it to the receiver which returns null because it is now full, so we have unnecessaily retrieved a message.
But the receiver knows it is full after accepting the last message.
So I suggest we add a flag on simple delivery to signify "receiver now full", this prevents the channel having to try delivery only to find it is rejected.
Any other solutions ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977556#3977556
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977556
19 years, 6 months
[Design of JBoss jBPM] - Status of web console enhancements
by david.lloyd@jboss.com
Right now I'm working on the new search mechanism for the web application. There are some items in the requirements (all of: the original, Tom's reworked one, and my reworked one on top of that) that I'm not 100% sure about, even now, so I'm still kinda thinking about those things. But the main recurring factor is that we need a good search/navigation system, and that's what I have in progress right now. A search mechanism is specified not only by the console requirements, but also the BAM application (which seems to overlap in functionality with the web console to a degree that remains to be seen).
The idea is to have a search mechanism that is very reusable. In this way, I hope to solve the problem with having multiple, similar searches by reducing the amount of effort required to create and maintain the different searches.
As far as implementation, I've come to the conclusion that the only real practical alternative is to use criteria queries to specify first the search results, and then add on any specified filter criteria. To attempt to maintain named queries for every kind of search would be hugely complicated.
Next will be to start integrating the search page into the pages of the web application, which should be the easy part, if I've done my job right.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977550#3977550
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977550
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
After the previous changes, I was able to create new ProcessInstances for an already deployed ProcessDefinition called 'Async' using a JMS standalone client, basically doing:
NewProcessInstanceCommand npic = new NewProcessInstanceCommand();
| npic.setProcessName("Async");
| //Setup for JMS session and producer using JNDI (omitted)
| ObjectMessage om = session.createObjectMessage();
| om.setObject(npic);
| producer.send(om);
The process instances are created, and I can see them into the Oracle database I'm using as datasource. But now, I'm a little confused about how to start those process instances:
My first attempt was to add to the 'start-state' node the attribute async with value 'true'. But it seems that's not valid under the DTD as I got that error while trying to deploy such process definition.
So, I guess that perhaps I should send a SignalCommand targetting that newly created process instance. To do so, it seems that I need to know the tokenId I want to signal (and it looks logical to me), but how could I know it from my JMS client.
What I'm going after is to be able to run the complete process inside the JBoss threads. I just want to launch it from the JMS client.
Why the start-state node can not be run asynchronously? Is that a design limitation?
Shouldn't I receive some feedback from my NewProcessInstanceCommand to know at least what ProcessInstance id I've launched (in order to send signals to that process instance tokens, for example) ?
What's the previousToken for, in the SignalCommand class ?
Regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977488#3977488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977488
19 years, 6 months