[JBoss JIRA] Commented: (JBESB-438) Controlled shutdown
by Kevin Conner (JIRA)
[ http://jira.jboss.com/jira/browse/JBESB-438?page=comments#action_12359665 ]
Kevin Conner commented on JBESB-438:
------------------------------------
Mark, can you elaborate on this please?
With the current codebase anything within a single .esb file should already be taken down cleanly.
The order used to specify the listeners/gateways is the sequence used by the managed lifecycle controller to initialise/start the lifecycles. When the managed lifecycle stops/destroys the …
[View More]lifecycles then the order is reversed.
Each listener/gateway should wait until current work has finished before being destroyed, subject to timeout.
Now that there is a move to deploy multiple .esb files we must make sure that the dependencies *between* those .esb files are fully realised. I do not believe the current codebase is in a position to do this and would have been happier if this had been deferred until 5 where we will have proper MC/OSGi integration.
> Controlled shutdown
> -------------------
>
> Key: JBESB-438
> URL: http://jira.jboss.com/jira/browse/JBESB-438
> Project: JBoss ESB
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Rosetta, Transports
> Affects Versions: 4.0
> Reporter: Mark Little
> Assigned To: Kevin Conner
> Fix For: 4.2 Milestone Release 2, 5.0 Milestone Release 1
>
>
> During a controlled shutdown, the ESB should prevent any further message inflow but allow all messages being processed/delivered to finish.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
17 years, 10 months
[JBoss JIRA] Created: (JBESB-501) remove action pipeline
by Kurt Stam (JIRA)
remove action pipeline
----------------------
Key: JBESB-501
URL: http://jira.jboss.com/jira/browse/JBESB-501
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.2 Milestone Release 1
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Fix For: 4.2 Milestone Release 2
I think we should discourage action pipelining as it muddies …
[View More]to waters. I think each action should be it's own service, and that all communication is service2service. This way each .esb archive does not have to package up all the Smooks jar (and dependencies). If we think this adds to much overhead then we should fix this by adding smarts to our framework, where it figures out if it can make a local call (go over a local transport). It also muddies the waters from the perspective of a service description if we allow action chaining.
This also removes the need for TwoWayCouriers, since we might as well forward it onto the next service, in stead of replying to the current one. I do think we should make an option for a blocking gateway, where the gateway waits for a a reply from an ESB Service.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
17 years, 10 months
[JBoss JIRA] Updated: (JBESB-192) Listener implementations need to perform the payload to Message wrapping, not the AbstractListener
by Tom Fennelly (JIRA)
[ http://jira.jboss.com/jira/browse/JBESB-192?page=all ]
Tom Fennelly updated JBESB-192:
-------------------------------
Fix Version/s: 4.2
(was: 5.0)
Affects Version/s: 4.2
(was: 4.0)
> Listener implementations need to perform the payload to Message wrapping, not the AbstractListener
> --------------------------------------------------------------------------------------------------
>
> Key: JBESB-…
[View More]192
> URL: http://jira.jboss.com/jira/browse/JBESB-192
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.2
> Reporter: Tom Fennelly
> Assigned To: Mark Little
> Priority: Blocker
> Fix For: 4.2
>
>
> I may be missing something here but, I think there's an issue with the Listeners/Action/Messages that probably requires more immediate attention.
> The AbstractListener calls the receive method of its implementation (DirectoryPoller etc) in order to get messages from the delivery channel associated with the implementation. At the moment, the receive method returns an Object[] and AbstractListener does the job of converting/wrapping these Objects into Message implementations before pushing the Message instances through the associated pipeline for processing. The AbstractListener also performs the job of triggering "lifecycle" events on the implementation i.e. processingError and processingComplete. In order for these method implementations to perform the appropriate "channel specific" tasks relating to the processing of the message, they need access to "special" info that should be hidden in the message and not accessible to anyone else other than that Listener impl. Hopefully this will make more sense through an example....
> The DirectoryPoller listens on the Filesystem for file based message. It manage the lifecycle of these messages as follows:
> 1. Before it's receive method impl returns the java.io.File associated with the message, it renames the file to "working" so that the file is not picked up for processing again. In fact, it actually returns an extension of java.io.File (WorkingFile) which contains "hidden" info that the Listener uses when message lifecycle events are called (processingError and processingComplete).
> 2. In response to a call to it's "processingError" implementation, it should get passed the original message object it returned from it's receive method (WorkingFile). WorkingFile is a inner class to DirectoryPoller and it contains a few private methods that only WorkingFile and DirectoryPoller can call. In the case of processingError being called, the DirectoryPoller wants to call the private method "renameToError".
> 3. In response to a call to it's "processingComplete" implementation, the DirectoryPoller wants to call the private method "renameToDone".
> The Issue:
> The AbstractListener implementations should be doing the wrapping of the message payload objects in the relevant Message implementations (not the AbstractListener itself as is currently the case). This way, the channel specific listener implementation can add the channel specific info it needs to the message before returning it for pipeline processing (e.g. the rename to error/done file names etc in the case of the DirectoryPoller). This also means that the receive method definition would need to be changed to return a Message[] (instead of an Object[]) and the lifecycle management methods (processingError and processingComplete) changed to take type Message (Vs type Object).
> Without making these changes, the lifecycle info will very likely get lost in the pipeline because it's currently being set on the Message body/payload, which will very likely get changed during pipeline processing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
17 years, 10 months
[JBoss JIRA] Closed: (JBESB-192) Listener implementations need to perform the payload to Message wrapping, not the AbstractListener
by Tom Fennelly (JIRA)
[ http://jira.jboss.com/jira/browse/JBESB-192?page=all ]
Tom Fennelly closed JBESB-192.
------------------------------
Resolution: Out of Date
> Listener implementations need to perform the payload to Message wrapping, not the AbstractListener
> --------------------------------------------------------------------------------------------------
>
> Key: JBESB-192
> URL: http://jira.jboss.com/jira/browse/JBESB-192
> Project: …
[View More]JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.2
> Reporter: Tom Fennelly
> Assigned To: Mark Little
> Priority: Blocker
> Fix For: 4.2
>
>
> I may be missing something here but, I think there's an issue with the Listeners/Action/Messages that probably requires more immediate attention.
> The AbstractListener calls the receive method of its implementation (DirectoryPoller etc) in order to get messages from the delivery channel associated with the implementation. At the moment, the receive method returns an Object[] and AbstractListener does the job of converting/wrapping these Objects into Message implementations before pushing the Message instances through the associated pipeline for processing. The AbstractListener also performs the job of triggering "lifecycle" events on the implementation i.e. processingError and processingComplete. In order for these method implementations to perform the appropriate "channel specific" tasks relating to the processing of the message, they need access to "special" info that should be hidden in the message and not accessible to anyone else other than that Listener impl. Hopefully this will make more sense through an example....
> The DirectoryPoller listens on the Filesystem for file based message. It manage the lifecycle of these messages as follows:
> 1. Before it's receive method impl returns the java.io.File associated with the message, it renames the file to "working" so that the file is not picked up for processing again. In fact, it actually returns an extension of java.io.File (WorkingFile) which contains "hidden" info that the Listener uses when message lifecycle events are called (processingError and processingComplete).
> 2. In response to a call to it's "processingError" implementation, it should get passed the original message object it returned from it's receive method (WorkingFile). WorkingFile is a inner class to DirectoryPoller and it contains a few private methods that only WorkingFile and DirectoryPoller can call. In the case of processingError being called, the DirectoryPoller wants to call the private method "renameToError".
> 3. In response to a call to it's "processingComplete" implementation, the DirectoryPoller wants to call the private method "renameToDone".
> The Issue:
> The AbstractListener implementations should be doing the wrapping of the message payload objects in the relevant Message implementations (not the AbstractListener itself as is currently the case). This way, the channel specific listener implementation can add the channel specific info it needs to the message before returning it for pipeline processing (e.g. the rename to error/done file names etc in the case of the DirectoryPoller). This also means that the receive method definition would need to be changed to return a Message[] (instead of an Object[]) and the lifecycle management methods (processingError and processingComplete) changed to take type Message (Vs type Object).
> Without making these changes, the lifecycle info will very likely get lost in the pipeline because it's currently being set on the Message body/payload, which will very likely get changed during pipeline processing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
17 years, 10 months