Ok, I think I understood your idea now.
It's basically a proxy, like the wire tap, which a chain of handlers configured
on it, right ?
yup. definitely more like the wire tap.
Note that for the static routing slip, the original exchange would be serialized
at least 3 * N times, N being the number of services invoked (once for in, out
and done exchanges), so in this case, I'm not sure it would be faster.
the serialized bytes could be stored as the property would would
potentially save some serialization overhead (and lazily deserialized
when you need it). not sure what the impact of carrying those bytes
around with you would be. depends on the network and the size of the
payloads (what i'm obviously ignoring is the amount of serialization /
deserialisation / storing to db that activemq is also doing).
when I first was looking at this, I assumed that there could be some
servicemix magic happening behind the scenes to optimise the stack of
exchanges which is why i put it on my feature wish list. it could also
just be the evil of premature optimisation clouding my judgement.
before i raise a jira, i'll try it out myself (when i get some more
time *sigh*) and if it looks like it performs reasonably vs. jdbcstore
i'll send in a patch.
thanks again for taking time out to follow this up.
cheers,
j.
On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > Still not sure to understand, sorry.
> > What is the added feature compared to
> > the routing slip EIP pattern [1] ?
>
> In Java terms, the routing slip feels like a series of method calls
> whereas a pipeline of components is more like a chain of decorators.
> For example, a natural way for me to introduce a component that
> records how long a downstream component takes to execute would be to
> add it in front of the component (i.e. all clients now call the
> timingcomponent) and it then calls the downstream component and times
> how long it takes. while this could be done with a static routing slip
> (i.e. have the slip call the timing component, then the real component
> then the timing component again), it doesn't feel like the tidiest way
> to do it. I could be wrong, though.
Ok, I think I understood your idea now.
It's basically a proxy, like the wire tap, which a chain of handlers configured
on it, right ?
Something like:
<eip:handler-chain>
<eip:target>
<eip:exchange-target service="test:xpathSplitter" />
</eip:target>
<eip:handlers>
... list of handler beans here ...
</eip:handler>
</eip:handler-chain>
> > Do you just want to
> > get rid of the store ? I guess we just need to send
> > the original exchange along with the requests to
> > services (as a property on the exchange). I think
> > the performances may be better if a few services
> > are used, else it may be more costly as the
> > original exchange will be serialized for each exchange
> > instead of only once.
>
> Yup, I mainly just want to get rid of the store to support the use
> case above. The clustered asynchronous static routing slip is also
> potentially expensive as it stores and serializes the exchange twice
> for each call too (once to database and once when sending).
>
> It would have to be the whole message history, though, which is why a
> stack of message exchanges (with some way to optimise the stack) would
> be useful. Just thought some more about the stack of delta's idea and
> it wouldn't work using standard JBI (i.e. you wouldn't be able to
> recreate a messageexchange from the stack unless it knows about
> messageexchangeimpl... hmm... unless it was the delta of the
> serialized bytes... okay too crazy). bother. That said, I'd still like
> it as an option.
>
> Just having an efficient way to support the message history pattern
> (http://www.enterpriseintegrationpatterns.com/MessageHistory.html)
> would be useful.
One of the problem when using clustered components, is the behavior
you want in case one node fails. Unless configured to do so, the NMR
will assume that when a component send an exchange, it may maintain
some state wrt to this exchange, hence the NMR will send the exchange
back to the same component instance (same node in a cluster). In such
a case, you can just keep the original exchange in memory. However,
if the node dies while waiting for the response, the exchange will be waiting
until the node is ready again.
The other way is to tell the NMR that the component does not maintain
any state or that this state is also clustered. This can be done
by setting the JbiConstants.STATELESS_CONSUMER property on the
exchange sent by the consumer, as done in the EIP component.
This allow the NMR to route the exchange to any component instance
in the cluster.
In the case of the pipeline you describe, there is a state to maintain, which
is at least the original exchange received by the component. If you want
the process to be asynchronous, you need to store this exchange somewhere
(either as part of the new exchange or in a persistent store).
Note that if you put the original exchange as a property in the new exchange,
the original exchange will be serialized each time the new exchange is also
serialized, which should be the same number of times (serialized only once),
but will be faster (as you do not need a remote jdbc call).
Note that for the static routing slip, the original exchange would be serialized
at least 3 * N times, N being the number of services invoked (once for in, out
and done exchanges), so in this case, I'm not sure it would be faster.
I guess nearly all EIP patterns could be improved to support such a store.
Btw, feel free to raise a JIRA on servicemix-eip.
>
> cheers,
> j.
>
> On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > Still not sure to understand, sorry.
> > What is the added feature compared to
> > the routing slip EIP pattern [1] ?
> >
> > This component already handle the asynchronous
> > reliable InOut patterns, but yes, it needs a store
> > to keep the original exchange. Do you just want to
> > get rid of the store ? I guess we just need to send
> > the original exchange along with the requests to
> > services (as a property on the exchange). I think
> > the performances may be better if a few services
> > are used, else it may be more costly as the
> > original exchange will be serialized for each exchange
> > instead of only once.
> >
> > [1]
http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-StaticRoutingSlip
> >
> > On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > hiya,
> > >
> > > > Could you be a bit more precise about your
> > > > wrapping / unwrapping operation ?
> > >
> > > one way to do this would be with a message history pattern. have a
> > > stack of ME's as an exchange property and just pop them as the
> > > in-out's come back through the pipeline.
> > >
> > > of course, that'd be hideously inefficient after a few hops. the stack
> > > could be smarter and just store delta's (that'd probably be useful for
> > > just doing the message history pattern too). if each component in the
> > > pipeline is changing the content radically then there still wouldn't
> > > be that much benefit but often intermediate components are doing
> > > aop-like things like logging, authentication, caching which don't
> > > actually touch the contents particularly much (of course, all of the
> > > previously mentioned use cases are catered for in other ways by
> > > servicemix but you get the idea).
> > >
> > > please let me know if you need more info.
> > >
> > > cheers,
> > > j.
> > >
> > > On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > Could you be a bit more precise about your
> > > > wrapping / unwrapping operation ?
> > > >
> > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > Hi,
> > > > >
> > > > > Not sure if this makes sense but:
> > > > >
> > > > > I'd like a way to do reliable / clustered / asynchronous in-out
> > > > > pipelining of message exchanges without having to use a JdbcStore. One
> > > > > way to do it would be to able to wrap message exchanges as they pass
> > > > > through each component in the pipeline (and then unwrap them on the
> > > > > way back).
> > > > >
> > > > > cheers,
> > > > > j.
> > > > >
> > > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > > ServiceMix is ultimately your project, and we need feedback
> > > > > > to help focus on what you think is needed to improve the project.
> > > > > >
> > > > > > If you have ever thought, "ServiceMix would be such a nice project,
if
> > > > > > only ...",
> > > > > > it' s time to speak !
> > > > > >
> > > > > > We'd like to hear from everyone, from beginners to advanced users,
> > > > > > so please fell free to speak and list the topics you'd like to
> > > > > > improve or new features to be implemented.
> > > > > >
> > > > > > Please, every user out there, give us your top 5 things we
> > > > > > can do to make ServiceMix better for you.
> > > > > >
> > > > > > --
> > > > > > Cheers,
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
--
Cheers,
Guillaume Nodet
