Hi Asankha, I understand that this is by design, but I guess I wasn't clear on my concerns. Let me rephrase them and I would separate them in 2 categories.
My 1st concern is that components that do not meet the framework characteristics should not be core components but rather sample or experimental and should be identifiable as such. Do we qualify the Callout mediator as a production grade component, which I'm having trouble since I don't think it is meeting the scalability characteristic. The solution could as simple as moving that component out of core into sample. That way it is clear to everyone. If we leave it into core, It make me wonder and bring into questioning other components and their characteristics, which is not something we want. My 2nd concern is that leaving the application to deal with asynchronous mediation is not the right place. This should be part of the framework. I can understand that this is not a trivial task as this also impact the way sequences are managed. e.g. how do we continue the sequence if one mediator goes asynchronous and return, how do we resume the sequence afterwards. Leaving those questions to the application developer may lead to quite some sequence mess and incompatible mediator interaction, maybe a solution would be to provide clear guideline. I'm not necessary looking at a short term fix but would like to understand when/if the ESB will be addressing those concerns. In the mean time, having a sample 431 included that does what you are suggesting would be nice so everyone can learn from your experience. Thanks Sylvain Legault On Wed, Oct 29, 2008 at 10:35 AM, Asankha C. Perera <[EMAIL PROTECTED]>wrote: > Hi Sylvain > >> One of the feature that got me interested into Synapse was the >> asynchronous >> aspect, but I then soon realize most mediator don't deal so well with this >> aspect. Callout, Atom to name a few. For me even if Synapse is >> asynchronous, >> but I have a mediator calling an external component synchronously, the >> system is now tighly couple to that external component and loose is >> scalability characteristic. I had to deal in the past with a similar >> system >> and one day the external component failed to respond to the HTTP request >> and >> the system was brought down, eventhough that external component was needed >> in only 2% of the traffic, at hight traffic the amount of threads blocked >> will bring your system down. >> >> Are there any plan to remedy to this? What is your view on this issue? >> > The callout mediator is designed to be "blocking".. but you could achieve > the same effect with the non-blocking manner, with the side effect that the > "current" message now becomes the response received. The easiest fix for > this is to make the original message accessible as well (we already have > that!) so that the user can decide how to merge these two for message > enrichment etc > > asankha >
