Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: neutral (nike.apache.org: 216.139.236.158 is neither permitted
 nor denied by domain of slew77@googlemail.com)
Date: Fri, 15 Oct 2010 07:30:41 -0700 (PDT)
From: slew <slew77@googlemail.com>
To: users@camel.apache.org
Message-ID: <1287153041909-3213809.post@n5.nabble.com>
In-Reply-To: <AANLkTi=r0u75qMbmagV1USXZ2tS507PWSqGC-VfP58Pd@mail.gmail.com>
References: <1287086705620-3212752.post@n5.nabble.com>
 <AANLkTimQVye_7apY79S-jFwQYc46v+MvaZuCWUAof3NC@mail.gmail.com>
 <1287089726454-3212817.post@n5.nabble.com>
 <AANLkTi=r0u75qMbmagV1USXZ2tS507PWSqGC-VfP58Pd@mail.gmail.com>
Subject: Re: Cross context connections, SEDA and BlockQueues
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for taking the time to answer Stan.  I'll have another go at trying =
to
get camel to convert the exception.  I have a snapshot of the 2010.02
servicemix-camel component which I think handles the jbi part, I'll try
updating to the latest to make sure I haven't just got a bug in my version.


Stan Lewis wrote:
>=20
> I believe the servicemix-camel component handles this already, i.e.
> it'll convert an exception to a JBI fault and send it back as a
> response, assuming the MEP allows for it.
>=20
> On Thu, Oct 14, 2010 at 4:55 PM, slew <slew77@googlemail.com> wrote:
>>
>> Hi Stan,
>>
>> Thanks for the response and clarifying the blocking queue question, make=
s
>> perfect sense now.
>>
>> I feel more comfortable about continuing with the JBI endpoints now, so
>> thanks again. =C2=A0One difficulty I'm having (i've posted this on the s=
mx
>> forum
>> today, so sorry if this counts as a repost), but I'm not sure about the
>> recommended way to propagate exceptions using the jbi component in camel=
.
>> As the exchange goes through the NMR, I guess the exceptions need to be
>> marshalled somehow, but I'm not sure of the recommended way to do this.
>> Should I trap the exceptions and convert them to a JBIFault manually or
>> should I let the camel component do some of this? =C2=A0I've tried setti=
ng the
>> convertException flag, but don't see any difference and in both cases
>> lose
>> the original exception. =C2=A0Alternatively, I can set a property on the
>> exchange
>> containing the exception and set the exchange as faulted, or turn the
>> exception into xml and propagate it that way as the fault body, but I
>> want
>> to make sure I'm not fighting the intended way of doing things and
>> missing
>> the recommended approach.
>>
>> Thanks for any more advice,
>> Steve.
>>
>>
>>
>> Stan Lewis wrote:
>>>
>>> Hi Steve,
>>>
>>> On Thu, Oct 14, 2010 at 4:05 PM, slew <slew77@googlemail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> In our application we have a routing slip that is configured at runtim=
e
>>>> to
>>>> invoke endpoints from "plugin" camel routes (camel 2.3) that are
>>>> provided
>>>> in
>>>> a separate camel context. =C2=A0We are using smx 3, so these plugins a=
re
>>>> packaged
>>>> as separate JBI assemblies.
>>>>
>>>> I'm trying to work out the best method to communicate between these
>>>> contexts. =C2=A0The original way I used was with the VM component. =C2=
=A0For
>>>> performance, I had to set the concurrentConsumers property, but this
>>>> has
>>>> a
>>>> drawback in that the consumer threads are fixed and so as the number o=
f
>>>> plugins increases the number of waiting threads increases.
>>>>
>>>> I've been looking at replacing this with JBI, as I'm currently using
>>>> SMX3.
>>>> This has thrown up some other questions, but as we'd look to move to
>>>> SMX4
>>>> at
>>>> some point (possibly soon) and JBI is not really the future of SMX, I'=
m
>>>> wondering if there are better alternatives.
>>>
>>> You can use JBI in either SMX3 or SMX4 so it's a good migration path,
>>> i.e. you should be able to continue using JBI endpoints when moving to
>>> SMX4 and then you can migrate them to something else. =C2=A0For new stu=
ff
>>> in SMX4 you can use the NMR component -
>>> http://camel.apache.org/nmr.html which I think might be better suited
>>> in an OSGi environment than the VM transport. =C2=A0And also you can al=
ways
>>> use JMS as well, probably more useful if you want to persist messages
>>> between routes to avoid losing messages.
>>>
>>>> Going back to the VM solution. =C2=A0The documentation has the followi=
ng:
>>>>
>>>>> Be aware that adding a thread pool to a SEDA endpoint by doing
>>>>> something
>>>>> like:
>>>>> from("seda:stageName").thread(5).process(...)
>>>>> Can wind up with two BlockQueues: one from the SEDA endpoint, and one
>>>>> from
>>>>> the workqueue of the thread pool, which may not be what you want.
>>>>
>>>> I'm not sure exactly what this means, could someone explain it to me
>>>> please
>>>> - really sorry if it's a thick question? =C2=A0I assume it's not sayin=
g
>>>> there's a
>>>> potential for a dead lock, but I can't work out what else it means.
>>>> =C2=A0Would
>>>> this be the correct approach in my scenario, i.e. so that more threads
>>>> are
>>>> working when the route is busy, less when it's not?
>>>
>>> I think it's a little typo, it should be BlockingQueues, meaning that
>>> a message would first go into the SEDA BlockingQueue, then wind up in
>>> the thread pool's BlockingQueue, so would introduce a performance
>>> impact.
>>>
>>>> Is there a better solution to this cross-context connections, e.g. JMS=
,
>>>> ActiveMQ. =C2=A0I like the VM approach as it works nicely with excepti=
on
>>>> propagation.
>>>>
>>>> I'd really appreciate anyones advice on this. =C2=A0Please let me know=
 if
>>>> you
>>>> need me to clarify anything.
>>>>
>>>> Thanks,
>>>> Steve.
>>>> --
>>>> View this message in context:
>>>> http://camel.465427.n5.nabble.com/Cross-context-connections-SEDA-and-B=
lockQueues-tp3212752p3212752.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>
>>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Cross-context-connections-SEDA-and-Blo=
ckQueues-tp3212752p3212817.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>=20
>=20

--=20
View this message in context: http://camel.465427.n5.nabble.com/Cross-conte=
xt-connections-SEDA-and-BlockQueues-tp3212752p3213809.html
Sent from the Camel - Users mailing list archive at Nabble.com.