You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Taylor Gautier <tg...@terracottatech.com> on 2008/03/09 16:53:03 UTC
Working Terracotta Component - Clustered Queues in Camel
Hello. I created a demonstration application that can send messages from one
VM to another using Terracotta. What you can do is create a special Camel
component that corresponds to a LinkedBlockingQueue that has been clustered
with Terracotta. This means that you can connect one Camel instance in one
VM to another Camel instance in another VM.
When you create a component in one Camel context, for example "tc:input"
that component will then be available in any other Camel context that is
using the TC Component.
The sample is simple to try out for yourself, assuming you have Maven (no
other infrastructure is required, as Maven will download and install
everything you need). Here's steps:
$ svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-camel
$ cd tim-camel
$ mvn clean install
$ cd sample
$ mvn tc:start
$ mvn tc:run
$ mvn tc:run
After the first tc:run, a receiver will startup. The second tc:run will
send 10 messages to the receiver.
So on the first console, you'll see this:
[INFO] [node] Starting camel context to receive messages
Then, the second:
[INFO] [node] Starting camel context to send messages
Then, the first console will report:
[INFO] [node] tc:input Test Message: 0
[INFO] [node] tc:input Test Message: 1
[INFO] [node] tc:input Test Message: 2
[INFO] [node] tc:input Test Message: 3
[INFO] [node] tc:input Test Message: 4
[INFO] [node] tc:input Test Message: 5
[INFO] [node] tc:input Test Message: 6
[INFO] [node] tc:input Test Message: 7
[INFO] [node] tc:input Test Message: 8
[INFO] [node] tc:input Test Message: 9
--
View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p15941549.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by cmoulliard <cm...@gmail.com>.
Thx. I will pick up the code from your svn server and test it.
One question :
According to this architecture (Camel + Terracotta), the
clustering/loadbalacing functionality is not provided by a ESB like
ServiceMix or Mule or using a cluster of JMS queues but by Terracotta. So,
conceptually speaking, Terracotta could play the role of an ESB except that
functionalities used to create/plug endpoints, services, ... are not part of
Terracotta package.
So, what do you think about the idea to embed Terracotta into a ESB product
(Mule, ServiceMix, ...) in order to provide such functionalities by default
? Terracotta could be part of the kernel engine of the ESB ?
Regards,
Charles
Taylor Gautier wrote:
>
> I haven't yet integrated the camel code into Camel proper. It currently
> lives on the Terracotta Forge site.
>
> You can check it out using:
>
> svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-camel
>
> Read the README.txt to run the sample.
>
>
> cmoulliard wrote:
>>
>> Hi,
>>
>> Can you tell me if the integration of Terracotta with Camel has been
>> finally integrated into the Camel project ? If this is the case, where
>> this code is located (in the source directory of Camel-core /
>> Camel-component) ?
>>
>> Regards
>>
>> Charles Moulliard
>> Senior Enterprise Architect
>> Xpectis - www.xpectis.com
>>
>>
>>
>> Taylor Gautier wrote:
>>>
>>>
>>> James.Strachan wrote:
>>>>
>>>> On 11/03/2008, Taylor Gautier <tg...@terracottatech.com> wrote:
>>>>> James.Strachan wrote:
>>>>>
>>>>> Will do. I'll go back and see if I can't commit the code - it's
>>>>> pretty
>>>>> small really. It seems like it would be better for this component to
>>>>> be a
>>>>> part of the camel package, rather than a separate download.
>>>>
>>>> Sure - so long as the license is fine (which at first look being MPL
>>>> based looks fine) we can host it at Apache if you like; or it could be
>>>> hosted at terracotta.org if you prefer; your call really.
>>>>
>>>
>>> Oh, I was thinking to donate it with an Apache license. Just have to
>>> get the OK on that, worst case we have it on TC site with TC license,
>>> but it seems better to be in Camel proper.
>>>
>>>
>>> James.Strachan wrote:
>>>>
>>>>> On a side note, does this usage make sense?
>>>>
>>>> Sure
>>>>
>>>>> I don't know Camel or its use
>>>>> cases well enough to know....for example, if you have an application
>>>>> with a
>>>>> JMS queue connecting one or more JVMs, how would that application be
>>>>> configured?
>>>>
>>>> So Camel works on endpoints; an endpoint being a specific queue or
>>>> topic or directory or whatever. The JMS endpoints are typically
>>>> created by a JmsComponent which has the various JMS configuration such
>>>> as ConnectionFactory or TransactionManager etc. We tend to use Spring
>>>> to configure that kinda stuff; though you can also configure endpoints
>>>> on the URI as well.
>>>> http://activemq.apache.org/camel/jms.html
>>>>
>>>>
>>>
>>> Ok, sounds like I did the right thing.
>>>
>>>
>>> James.Strachan wrote:
>>>>
>>>>> I think I have modeled what I have done roughly on this usage, but
>>>>> I'm not
>>>>> an expert here. I'd love to see someone who has more experience give
>>>>> this a
>>>>> try in a more real-world setting - I would suspect that it might be
>>>>> possible
>>>>> for any app that has a JMS queue configured as endpoints between two
>>>>> JVMs
>>>>> this would work pretty much as a drop in replacement, but again, not
>>>>> really
>>>>> sure here.
>>>>
>>>> Sure - wanna pop the code somewhere and we can take a noodle?
>>>>
>>>
>>> It's already there - in my original message I posted a working sample
>>> that should take about 1 minute to run - it all builds and compiles and
>>> downloads via maven, so the checkout is next to nothing.
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p16823741.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by Taylor Gautier <tg...@terracottatech.com>.
I haven't yet integrated the camel code into Camel proper. It currently
lives on the Terracotta Forge site.
You can check it out using:
svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-camel
Read the README.txt to run the sample.
cmoulliard wrote:
>
> Hi,
>
> Can you tell me if the integration of Terracotta with Camel has been
> finally integrated into the Camel project ? If this is the case, where
> this code is located (in the source directory of Camel-core /
> Camel-component) ?
>
> Regards
>
> Charles Moulliard
> Senior Enterprise Architect
> Xpectis - www.xpectis.com
>
>
>
> Taylor Gautier wrote:
>>
>>
>> James.Strachan wrote:
>>>
>>> On 11/03/2008, Taylor Gautier <tg...@terracottatech.com> wrote:
>>>> James.Strachan wrote:
>>>>
>>>> Will do. I'll go back and see if I can't commit the code - it's pretty
>>>> small really. It seems like it would be better for this component to
>>>> be a
>>>> part of the camel package, rather than a separate download.
>>>
>>> Sure - so long as the license is fine (which at first look being MPL
>>> based looks fine) we can host it at Apache if you like; or it could be
>>> hosted at terracotta.org if you prefer; your call really.
>>>
>>
>> Oh, I was thinking to donate it with an Apache license. Just have to get
>> the OK on that, worst case we have it on TC site with TC license, but it
>> seems better to be in Camel proper.
>>
>>
>> James.Strachan wrote:
>>>
>>>> On a side note, does this usage make sense?
>>>
>>> Sure
>>>
>>>> I don't know Camel or its use
>>>> cases well enough to know....for example, if you have an application
>>>> with a
>>>> JMS queue connecting one or more JVMs, how would that application be
>>>> configured?
>>>
>>> So Camel works on endpoints; an endpoint being a specific queue or
>>> topic or directory or whatever. The JMS endpoints are typically
>>> created by a JmsComponent which has the various JMS configuration such
>>> as ConnectionFactory or TransactionManager etc. We tend to use Spring
>>> to configure that kinda stuff; though you can also configure endpoints
>>> on the URI as well.
>>> http://activemq.apache.org/camel/jms.html
>>>
>>>
>>
>> Ok, sounds like I did the right thing.
>>
>>
>> James.Strachan wrote:
>>>
>>>> I think I have modeled what I have done roughly on this usage, but I'm
>>>> not
>>>> an expert here. I'd love to see someone who has more experience give
>>>> this a
>>>> try in a more real-world setting - I would suspect that it might be
>>>> possible
>>>> for any app that has a JMS queue configured as endpoints between two
>>>> JVMs
>>>> this would work pretty much as a drop in replacement, but again, not
>>>> really
>>>> sure here.
>>>
>>> Sure - wanna pop the code somewhere and we can take a noodle?
>>>
>>
>> It's already there - in my original message I posted a working sample
>> that should take about 1 minute to run - it all builds and compiles and
>> downloads via maven, so the checkout is next to nothing.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p16823278.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by cmoulliard <cm...@gmail.com>.
Hi,
Can you tell me if the integration of Terracotta with Camel has been finally
integrated into the Camel project ? If this is the case, where this code is
located (in the source directory of Camel-core / Camel-component) ?
Regards
Charles Moulliard
Senior Enterprise Architect
Xpectis - www.xpectis.com
Taylor Gautier wrote:
>
>
> James.Strachan wrote:
>>
>> On 11/03/2008, Taylor Gautier <tg...@terracottatech.com> wrote:
>>> James.Strachan wrote:
>>>
>>> Will do. I'll go back and see if I can't commit the code - it's pretty
>>> small really. It seems like it would be better for this component to
>>> be a
>>> part of the camel package, rather than a separate download.
>>
>> Sure - so long as the license is fine (which at first look being MPL
>> based looks fine) we can host it at Apache if you like; or it could be
>> hosted at terracotta.org if you prefer; your call really.
>>
>
> Oh, I was thinking to donate it with an Apache license. Just have to get
> the OK on that, worst case we have it on TC site with TC license, but it
> seems better to be in Camel proper.
>
>
> James.Strachan wrote:
>>
>>> On a side note, does this usage make sense?
>>
>> Sure
>>
>>> I don't know Camel or its use
>>> cases well enough to know....for example, if you have an application
>>> with a
>>> JMS queue connecting one or more JVMs, how would that application be
>>> configured?
>>
>> So Camel works on endpoints; an endpoint being a specific queue or
>> topic or directory or whatever. The JMS endpoints are typically
>> created by a JmsComponent which has the various JMS configuration such
>> as ConnectionFactory or TransactionManager etc. We tend to use Spring
>> to configure that kinda stuff; though you can also configure endpoints
>> on the URI as well.
>> http://activemq.apache.org/camel/jms.html
>>
>>
>
> Ok, sounds like I did the right thing.
>
>
> James.Strachan wrote:
>>
>>> I think I have modeled what I have done roughly on this usage, but I'm
>>> not
>>> an expert here. I'd love to see someone who has more experience give
>>> this a
>>> try in a more real-world setting - I would suspect that it might be
>>> possible
>>> for any app that has a JMS queue configured as endpoints between two
>>> JVMs
>>> this would work pretty much as a drop in replacement, but again, not
>>> really
>>> sure here.
>>
>> Sure - wanna pop the code somewhere and we can take a noodle?
>>
>
> It's already there - in my original message I posted a working sample that
> should take about 1 minute to run - it all builds and compiles and
> downloads via maven, so the checkout is next to nothing.
>
>
--
View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p16823108.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by Taylor Gautier <tg...@terracottatech.com>.
James.Strachan wrote:
>
> On 11/03/2008, Taylor Gautier <tg...@terracottatech.com> wrote:
>> James.Strachan wrote:
>>
>> Will do. I'll go back and see if I can't commit the code - it's pretty
>> small really. It seems like it would be better for this component to be
>> a
>> part of the camel package, rather than a separate download.
>
> Sure - so long as the license is fine (which at first look being MPL
> based looks fine) we can host it at Apache if you like; or it could be
> hosted at terracotta.org if you prefer; your call really.
>
Oh, I was thinking to donate it with an Apache license. Just have to get
the OK on that, worst case we have it on TC site with TC license, but it
seems better to be in Camel proper.
James.Strachan wrote:
>
>> On a side note, does this usage make sense?
>
> Sure
>
>> I don't know Camel or its use
>> cases well enough to know....for example, if you have an application
>> with a
>> JMS queue connecting one or more JVMs, how would that application be
>> configured?
>
> So Camel works on endpoints; an endpoint being a specific queue or
> topic or directory or whatever. The JMS endpoints are typically
> created by a JmsComponent which has the various JMS configuration such
> as ConnectionFactory or TransactionManager etc. We tend to use Spring
> to configure that kinda stuff; though you can also configure endpoints
> on the URI as well.
> http://activemq.apache.org/camel/jms.html
>
>
Ok, sounds like I did the right thing.
James.Strachan wrote:
>
>> I think I have modeled what I have done roughly on this usage, but I'm
>> not
>> an expert here. I'd love to see someone who has more experience give
>> this a
>> try in a more real-world setting - I would suspect that it might be
>> possible
>> for any app that has a JMS queue configured as endpoints between two
>> JVMs
>> this would work pretty much as a drop in replacement, but again, not
>> really
>> sure here.
>
> Sure - wanna pop the code somewhere and we can take a noodle?
>
It's already there - in my original message I posted a working sample that
should take about 1 minute to run - it all builds and compiles and downloads
via maven, so the checkout is next to nothing.
--
View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p15979496.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by James Strachan <ja...@gmail.com>.
On 11/03/2008, Taylor Gautier <tg...@terracottatech.com> wrote:
> James.Strachan wrote:
> >
> > Great stuff! :)
> >
> > We should add a link to this on the Camel wiki
> >
>
>
> Will do. I'll go back and see if I can't commit the code - it's pretty
> small really. It seems like it would be better for this component to be a
> part of the camel package, rather than a separate download.
Sure - so long as the license is fine (which at first look being MPL
based looks fine) we can host it at Apache if you like; or it could be
hosted at terracotta.org if you prefer; your call really.
> On a side note, does this usage make sense?
Sure
> I don't know Camel or its use
> cases well enough to know....for example, if you have an application with a
> JMS queue connecting one or more JVMs, how would that application be
> configured?
So Camel works on endpoints; an endpoint being a specific queue or
topic or directory or whatever. The JMS endpoints are typically
created by a JmsComponent which has the various JMS configuration such
as ConnectionFactory or TransactionManager etc. We tend to use Spring
to configure that kinda stuff; though you can also configure endpoints
on the URI as well.
http://activemq.apache.org/camel/jms.html
> I think I have modeled what I have done roughly on this usage, but I'm not
> an expert here. I'd love to see someone who has more experience give this a
> try in a more real-world setting - I would suspect that it might be possible
> for any app that has a JMS queue configured as endpoints between two JVMs
> this would work pretty much as a drop in replacement, but again, not really
> sure here.
Sure - wanna pop the code somewhere and we can take a noodle?
One of the main benefits of Camel is it abstracts all the middleware &
transport protocols from you; so its pretty trivial to switch from in
memory SEDA queues to JMS to databases to Terracotta to JavaSpaces to
FIX to file systems, Atom or whatever.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by Taylor Gautier <tg...@terracottatech.com>.
James.Strachan wrote:
>
> Great stuff! :)
>
> We should add a link to this on the Camel wiki
>
Will do. I'll go back and see if I can't commit the code - it's pretty
small really. It seems like it would be better for this component to be a
part of the camel package, rather than a separate download.
On a side note, does this usage make sense? I don't know Camel or its use
cases well enough to know....for example, if you have an application with a
JMS queue connecting one or more JVMs, how would that application be
configured?
I think I have modeled what I have done roughly on this usage, but I'm not
an expert here. I'd love to see someone who has more experience give this a
try in a more real-world setting - I would suspect that it might be possible
for any app that has a JMS queue configured as endpoints between two JVMs
this would work pretty much as a drop in replacement, but again, not really
sure here.
--
View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p15974075.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Working Terracotta Component - Clustered Queues in Camel
Posted by James Strachan <ja...@gmail.com>.
Great stuff! :)
We should add a link to this on the Camel wiki
On 09/03/2008, Taylor Gautier <tg...@terracottatech.com> wrote:
>
> Hello. I created a demonstration application that can send messages from one
> VM to another using Terracotta. What you can do is create a special Camel
> component that corresponds to a LinkedBlockingQueue that has been clustered
> with Terracotta. This means that you can connect one Camel instance in one
> VM to another Camel instance in another VM.
>
> When you create a component in one Camel context, for example "tc:input"
> that component will then be available in any other Camel context that is
> using the TC Component.
>
> The sample is simple to try out for yourself, assuming you have Maven (no
> other infrastructure is required, as Maven will download and install
> everything you need). Here's steps:
>
> $ svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-camel
> $ cd tim-camel
> $ mvn clean install
> $ cd sample
> $ mvn tc:start
> $ mvn tc:run
> $ mvn tc:run
>
> After the first tc:run, a receiver will startup. The second tc:run will
> send 10 messages to the receiver.
>
> So on the first console, you'll see this:
>
> [INFO] [node] Starting camel context to receive messages
>
> Then, the second:
>
> [INFO] [node] Starting camel context to send messages
>
> Then, the first console will report:
>
> [INFO] [node] tc:input Test Message: 0
> [INFO] [node] tc:input Test Message: 1
> [INFO] [node] tc:input Test Message: 2
> [INFO] [node] tc:input Test Message: 3
> [INFO] [node] tc:input Test Message: 4
> [INFO] [node] tc:input Test Message: 5
> [INFO] [node] tc:input Test Message: 6
> [INFO] [node] tc:input Test Message: 7
> [INFO] [node] tc:input Test Message: 8
> [INFO] [node] tc:input Test Message: 9
>
>
>
> --
> View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p15941549.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com