[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update
by clebert.suconic@jboss.com
"Tim Fox" wrote :
| For non large messages, delivery to the client only occurs when the replication response has come back from the server. If you just do it the same as that, then should be ok?
No... This is how I used to do it, and it took me a while to figure why it was not working.
For non large messages, you're sure you will finish the delivery of the message when the replication response has come back.
However for largeMessages it doesn't work this way.
As you could interrupt chunk-delivery of the largeMessage waiting for more credits, if eventually ServerConsumer::handle is called with another message it should reject the handle being considered busy.
Doing the LargeMessageDeliver only after the response is back would cause several issues on the flowControl of the delivery.
"Tim Fox" wrote :
| Sorry, didn't understand that explanation.
This has to do with my previous explanation.
When getting the credit replicated on BackupNode, it will eventually resume delivering the LargeMessage, if it ran out of credit before.
That resume has also to be done synchronously or else the results are unpredictable. We would eventually get another message on handle while still delivering the first message.
"Tim Fox" wrote :
| What is ClientRemoteConsumer?
I meant to say RemotingConnectionImpl.
But more specifically, the PacketHandler on the client.
On largeMessageContinuations, flowControl is being called inside the handlePacket method, and failover will dead lock if it fails while the credit is being sent to the server. Using an executor on flowControl on messageContinuations fixed the problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201838#4201838
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201838
17 years, 2 months
[Design of JBoss jBPM] - Re: First look at jBPM4 Alpha1
by kukeltje
Thomas,
Good review. I tend to agree with most of what you write although I've only downloaded it yesterday, so I did not try much yet.
I definately agree on the namespace thing ;-) and regarding terminology, I tend to agree as well but with some small remarks.
BPMN terminology is not always 1-1 mappable on jBPM terminology, or e.g. a drop-in replacement. Therefor I think it should be introduced slowly and since it will not be 100% BPMN, there will be discrepancies. The join/fork comment I agree with (although it takes getting used to, so initially we should mention the 'old' term i
n braces as wel), regarding the events etc, lets introduce them slowly and see where it leads us.
On thing I think differently about though
anonymous wrote : I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR)
I think that not doing this would result in a lot of misunderstanding with the current users. They are so accustomed to having this that if we have the intention to support this condensing, we should do it now. It should be a little more explained then I agree what the behaviour is.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201809#4201809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201809
17 years, 2 months
[Design of JBoss jBPM] - First look at jBPM4 Alpha1
by thomas.diesler@jboss.com
First of all, congratulation for getting out the long awaited release - well done.
I got the download from SF, installed the GPD, read the docs, had a look at the API and generally tried a few things - here my impressions. May it be helpful ;-)
The new graphical designer (GPD) looks really nice. It finally adopts the BPMN standard for its graphical elements, which looks really nice.
There is the notion of start event, and end event, a few gateway types and a significant number of tasks.
What is a little bit confusing is some inconsistency in the terminology that is being used in the GPD, the docs and the API. BPMN talks about exclusive, inclusive, parallel and complex gateways. These have a specific semantics and everybody who knows BPMN would also know their semantics. GPD on the other hand talks about exclusive, fork, join
The jbpm4 docs sais
anonymous wrote :
| (BPMN note: when we mention activities here, we are not only refering to BPMN activities, but also to BPMN events and BPMN gateways.)
|
If possible, I would not do that. An activity is an activity (namely a task or a sub-process), an event is an event, a gateway is a gateway.
jBPM4 allows multiple outgoing flows on a task. This combines the notion of task with the notion of gateway. It is however not clear what type of gateway is being combined here and if we assume that it is an exclusive gateway, it not clear whether the full functional set of an exclusive gateway is also available on the task.
Can every task have multiple outgoing flows?
I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR)
The docs talk about "end state" - this should be "end event" - cancel and error are "event details" that if attached to an end event are called "result"
Generally, I'd recommend not to invent new terminology for a concept in the BPMN editor that already has a "standard" name in BPMN. Also don't use existing BPMN terminology to mean something different.
The API combines the notion of ProcessInstance with that of Token in a single interface and calls it "Execution". This will not allow these two concepts to evolve independently for example when you want to add state independently to the ProcessInstance and the Token. It is generally better to model a concept like ProcessInstance as such and call it by it's name. If you cant do much (yet) with a ProcessInstance you will have a short method list, which is ok.
The GPD elements in the process definition should be defined in their own namespace
Instead of
| <start g="32,22,80,40">
|
jBPM should have
| <start gpd:g="32,22,80,40">
|
This allows GPD metadata to evolve independently of the process definition itself and also makes it clear that 'g' is a presentational and not a functional element.
During GPD installation, the license text is missing.
This sounds like a lot of criticism, but my general impression is good. The docs cover sufficiently what is there already. Designer and implementation seem to be in sync. The list of examples covers available functionality.
Thanks for Alpha1, I'm looking forward to stuff to come.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201795#4201795
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201795
17 years, 2 months
[Design the new POJO MicroContainer] - Re: MutableClassInfo?
by stale.pedersen@jboss.org
"adrian(a)jboss.org" wrote :
| This just lets you create a ClassInfo from the bytecode.
| But for this to work properly it needs to have a understanding as to which
| classloader the class/bytecode should be assigned.
|
yes, well yes and no. when creating a CtClass object yes, when creating a ClassFile object then no. as mentioned ClassFile is a impl detail, but we need the functionality it brings. - but if we can implement what we currently need from ClassFile to *ClassInfo* then no.
eg, atm we can:ClassFile cf = new ClassFile( new DataInputStream(new FileInputStream(file)));
"adrian(a)jboss.org" wrote :
| "stale.pedersen(a)jboss.org" wrote :
| | - do finegrained operations/checks ala annotation visibility (which is only possible with javassist and not java.lang.reflect afaik)
| |
|
| Not sure why you need this. I assume you mean being able to look
| at annotations that are not Runtime visible? Is that really a good idea?
|
we use it a lot in aop so yes, we need it.
"adrian(a)jboss.org" wrote :
| Unless you mean being able to get the resulting byte code from the manipulation
| so you can defineClass() on it I don't think it is a good idea.
|
| Allowing access to implementation details is not a good idea,
| e.g. the deprecated TypeInfo.getClass() should not be there.
|
| Instead we need to extend the abstraction to make this unnecessary.
| This could include some helper methods to defineClass() from a ClassInfo.
|
i was not thinking of getting the .class. i was thinking of something like CtClass.getClassFile() since atm that is the only way we can get info like annotation visibility, but if we can implement to get that from TypeInfo/etc its not needed.
for now we havent added any methods to add/change methods/fields/etc to ClassInfo, we just changed the factory to not use the .class representation when creating the ClassInfo object to use the CtClass instead. - which i guess it was meant to anyway if im understanding adrian correct.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201779#4201779
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201779
17 years, 2 months