[Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience
by mark.little＠jboss.com
"tfennelly" wrote : Basically, the ActionProcessor definition seems fundamentally flawed to me in that notification generation (OK and Error) is done seperately from the message processing to which it is inextricably tied.
|
OK, now I understand. The issue is that the model worked fine before the pipeline change went in, but now it does not fit. In the model prior to pipelining, the notification of success or failure was implicitly tied to the message/object that was used to perform the work. Now it isn't, particularly if we let pipelines continue in the event of a failure.
anonymous wrote :
| That's what I meant originally when I said that I thought it was "dodgy". The way I see this, saving before/after/whatever objects is not going to fix this properly - the notifications need to be generated in context i.e. in line with the message processing to which they are tied.
|
I'm not convinced that the pipelining architecture has been fully thought out in terms of errors and successes. It seems like the chaining of "do work" is fine, but how errors or sucess notifications play in this hasn't been fully appreciated. We need to revisit that. BTW, if you raised this as a potential issue when doing the original pipelining work, then it's my fault for not catching it.
anonymous wrote :
| Doing it any other way is always going to cause trouble for somone. Whether or not this is sorted out for the GA is (I think) a question of how important Notifications are for the GA.
|
Sounds like a fundamental issue to me.
anonymous wrote :
| I suggested somewhere else that we could implement a notification mechanism by allowing the process method impls add notification objects to the Message.
|
Fault's are faults. If an error happens and the element in the chain needs to inform the caller, then the chain processing should stop immediately and return an appropriate message to the caller. The issue at this stage will be that the element in the chain may need to know it was working in a pipeline. However, that's a contract issue and can be fixed later IMO.
I would say that both the success and error notifications go to the entity managing the pipeline. If it gets an error then it immediately returns that error message to the caller. If it gets a success then it either returns that message to the caller if there are no other entries in the chain, or it simply calls the next entry in the chain.
anonymous wrote :
| A list of notifications (info, warn, error) could accumulate on the message as it flows through the pipeline
|
They could, but I would prefer a much simpler approach: signalling an error notification means "terminate processing and return the notification to the caller"; if the ActionProcessor wants to chain faults that don't really have a significant impact on processing, or warning messages, then it can embed them in the body of the message to be sent on to the next entry in the pipeline. This is an application specific issue at this stage. How (and if) the last entry in the pipeline chooses to then send those chained warnings back to the caller is up to it.
anonymous wrote : , being sent once the pipeline processing is complete (the notification list retrieved from the message via some form of getter). This may need to tie in in some way with the message Fault??
|
Once we have support for EPRs within the architecture, using the Fault message (and the FaultTo EPR of the Call) would be the natural way to handle this.
anonymous wrote :
| This would also enable an ActionProcessor impl to send multiple notifications from within the context of the processing of a single message.
Starting to sound complex. Let's stick with Occam's Razor for now and K.I.S.S. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976935#3976935
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976935
19 years, 6 months
[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by mark.little＠jboss.com
"reverbel" wrote : "mark.little(a)jboss.com" wrote : "reverbel" wrote :
| | | Instead of embedding a full Xid into, say, the object id part of an IOR, the OTS/DTM code uses a long (the local transaction id) as the CORBA object id. Besides reducing wire traffic and marshalling overhead, this approach reduces logging overhead, as it reduces the size of transaction log records that contain Resource or Coordinator references.
| | |
| |
| | I will just say that the problems with storing anything that isn't guaranteed to be globally unique are fairly obvious and risky where transaction processing is concerned.
|
| Not sure what was your point here... Resource and Coordinator references are globally unique, as each such reference contains endpoint info such as host and port, plus a local id field that is unique within that endpoint. Usage of "really local" ids (rather than using full Xids as local id values) avoids nesting of globally unique identifiers, which would be a wasteful thing to do.
|
| Regards,
|
| Francisco
But if these longs or integers are being stored with the log as a reference to a Resource/Coordinator/Xid, then eventually your identifier will wrap. This means that it's possible for the same id to be used to key into different Resource/Coordinator/Xids at the same time.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976928#3976928
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976928
19 years, 6 months
[Design of JBoss ESB] - Re: Trailblazer out-of-the-box experience
by tfennelly
Basically, the ActionProcessor definition seems fundamentally flawed to me in that notification generation (OK and Error) is done seperately from the message processing to which it is inextricably tied. That's what I meant originally when I said that I thought it was "dodgy". The way I see this, saving before/after/whatever objects is not going to fix this properly - the notifications need to be generated in context i.e. in line with the message processing to which they are tied. Doing it any other way is always going to cause trouble for somone. Whether or not this is sorted out for the GA is (I think) a question of how important Notifications are for the GA.
I suggested somewhere else that we could implement a notification mechanism by allowing the process method impls add notification objects to the Message. A list of notifications (info, warn, error) could accumulate on the message as it flows through the pipeline, being sent once the pipeline processing is complete (the notification list retrieved from the message via some form of getter). This may need to tie in in some way with the message Fault?? This would also enable an ActionProcessor impl to send multiple notifications from within the context of the processing of a single message.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976924#3976924
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976924
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by tom.baeyens＠jboss.com
"mteira" wrote : While I wait for your answer, here is the link to one of the problems I've found:
| http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92188
|
|
That will probably have to do with the classloading. By default, .war's are loaded in a separate classloading environment that can see the libraries in the server's lib folder and the classes and libs defined in the .war's itself.
.ears have a different classloading mechanism. By default, the .ear's are loaded in the global classpath. (Meaning that they share the same classloader repository as the global classloader).
So classes in .ear files will be visible to the global classpath and classes in .war files are not (by default).
I'm not yet sure, but i can only expect that this problem somehow must boil down to that.
"mteira" wrote : I'm thinking that perhaps a workaround could be to comment out the 'web' descriptor in the application.xml ear file, and deploy into my jboss both the console war and the jbpm.ear.
|
|
if that works for you, it could be a temporary workaround.
"mteira" wrote :
| Is there any code in the repository to test the JMS service messaging from the client side?
|
indeed. i was busy trying to create the .ear packaging when i got interrupted in this line of work. so here's the todo in the sequence that i had in mind:
1) create a decent .ear packaging with jbpm and the mdb and the slsb. the packaging should also contain the configuration that binds the jbpm messaging service to JMS.
2) create a test set up so that messaging can be tested. i got started on this by incorporating cactus. i have one cactus test somewhere that is able to print a log message inside of jboss.
3) create test cases that execute processes with async="true" and run these inside of the container and check if the JMS queues contain the proper jobs.
"mteira" wrote :
| Looking at the code it seems to me that what I need is to create those Command subclass object (for example, a NewProcessInstanceCommand) and just send it to the queue where the CommandListener MDB is attached.
|
yes.
"mteira" wrote :
| Anyway, as the Command subclasses don't have a constructor, and a lot of getter and setter methods, I'm not sure of what setter methods should be invoked to create a valid Command object, but I suppose that it depends on the subclass I'm using.
|
use the setters. the commands are a work in progress. note that the use cases for commands are still being discovered/examined. e.g. relation between web services and commands still needs to be worked out in detail. it could be that the commands will be subject to change.
after the use cases for commands become clear and they have stabilized a bit, we can start creating convenience constructors.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976921#3976921
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976921
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
Hello again.
In my quest for the "working jBPM-JMS environment" I've found a new problems, and I'm wondering if this is the right forum to inform about them. I posted one of them in the Users Forum, but then, I thought that perhaps this is a better place since CVS version and new features are involved.
So, what is the preferable way to proceed. Post them here? Open JIRA bugs directly?
While I wait for your answer, here is the link to one of the problems I've found:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92188
I'm thinking that perhaps a workaround could be to comment out the 'web' descriptor in the application.xml ear file, and deploy into my jboss both the console war and the jbpm.ear.
Is there any code in the repository to test the JMS service messaging from the client side? I mean, something able to create the Command objects, and send them to the proper JMS queue. Looking at the code it seems to me that what I need is to create those Command subclass object (for example, a NewProcessInstanceCommand) and just send it to the queue where the CommandListener MDB is attached. Anyway, as the Command subclasses don't have a constructor, and a lot of getter and setter methods, I'm not sure of what setter methods should be invoked to create a valid Command object, but I suppose that it depends on the subclass I'm using.
Any comment about this "memory dump" ?
Regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976903#3976903
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976903
19 years, 6 months