You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@streams.apache.org by Jason Letourneau <jl...@gmail.com> on 2013/10/01 02:36:45 UTC
Re: Use of ActiveMQ
Yes - as a deployment decision, they could be on separate servers.
On Mon, Sep 30, 2013 at 9:31 AM, Danny Sullivan <ds...@hotmail.com> wrote:
> Concerning adding "multiple outbound routes for http" as a way to get around "point to point messaging", aren't we already adding multiple outbound routes for http for delivering activities to individual subscribers? Perhaps I'm misunderstanding the architecture. From what I understand, the current architecture allows for an activity to be posted and stored on a single server and that message is sent to the same server via JMS (ActiveMQ). Are we talking about an architecture where all of these components (ActivityAggregator, SubscriberWarehouse, Registration) are all on separate servers? If that is the case, then I can understand the usage of ActiveMQ, but I don't understanding sending a message via JMS from one server to the same server.
> Thanks!
>
> Danny
>
>> From: dsullivan7@hotmail.com
>> To: dev@streams.incubator.apache.org
>> Subject: RE: Use of ActiveMQ
>> Date: Thu, 19 Sep 2013 16:19:42 -0400
>>
>> Good to know, thanks for the info!
>>
>> > Date: Thu, 19 Sep 2013 16:17:52 -0400
>> > Subject: Re: Use of ActiveMQ
>> > From: jletourneau80@gmail.com
>> > To: dev@streams.incubator.apache.org
>> >
>> > Yeah that stuff too ;)
>> >
>> > On Thu, Sep 19, 2013 at 4:14 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
>> > > Failover, load_balancing......
>> > >
>> > >
>> > > On Thu, Sep 19, 2013 at 1:13 PM, Jason Letourneau
>> > > <jl...@gmail.com>wrote:
>> > >
>> > >> Performance more than anything for passing between components but also
>> > >> for advanced messaging patterns or systems that might be interested in
>> > >> wiretapping the JMS queues - http would lock us into point to point
>> > >> messaging between all the components, though I guess you could just
>> > >> add multiple outbound routes for http...
>> > >>
>> > >> On Thu, Sep 19, 2013 at 3:18 PM, Danny Sullivan <ds...@hotmail.com>
>> > >> wrote:
>> > >> > Hey Everyone,
>> > >> > Is there a reason to use ActiveMQ in Streams at all? I noticed the
>> > >> following in the streamsCamelContext.xml:
>> > >> > <!--split activities on Q, waiting for aggregation --> <route>
>> > >> <from uri="direct:activityQ"/> <inOnly
>> > >> uri="activemq:queue:activities"/> </route>
>> > >> > <route> <from uri="activemq:queue:activities"/>
>> > >> <aggregate completionInterval="500" groupExchanges="true">
>> > >> <correlationExpression> <constant>true</constant>
>> > >> </correlationExpression> <bean
>> > >> ref="activityService" method="receiveExchange"/> </aggregate>
>> > >> </route>
>> > >> >
>> > >> > I replace this with the following and got the same functionality:
>> > >> > <!--split activities on Q, waiting for aggregation --> <route>
>> > >> <from uri="direct:activityQ"/> <aggregate
>> > >> completionInterval="500" groupExchanges="true">
>> > >> <correlationExpression> <constant>true</constant>
>> > >> </correlationExpression> <bean
>> > >> ref="activityService" method="receiveExchange"/> </aggregate>
>> > >> </route>
>> > >> > This makes sense conceptually because what we currently have is a POST
>> > >> method reaching the server and being sent to the same server via JMS. Is
>> > >> there a reason to use a messaging system rather than have the streams sent
>> > >> and received via http? Either Camel or Spring MVC should be able to
>> > >> accomplish this. What I'd like to do is set up single endpoints for
>> > >> publisher registration, subscriber registration, publishing streams, and
>> > >> receiving streams in Camel (because Storm unfortunately doesn't look like
>> > >> it provides support for http routing). Storm would process all the data
>> > >> coming in from Camel and output it to the Cassandra DB. Receiving streams
>> > >> would operate much in the same way it currently does: by refreshing the
>> > >> stream from the database.
>> > >> > Danny
>> > >>
>>
>
RE: Use of ActiveMQ
Posted by Danny Sullivan <ds...@hotmail.com>.
Excellent, sounds good
> Date: Mon, 30 Sep 2013 20:36:45 -0400
> Subject: Re: Use of ActiveMQ
> From: jletourneau80@gmail.com
> To: dev@streams.incubator.apache.org
>
> Yes - as a deployment decision, they could be on separate servers.
>
> On Mon, Sep 30, 2013 at 9:31 AM, Danny Sullivan <ds...@hotmail.com> wrote:
> > Concerning adding "multiple outbound routes for http" as a way to get around "point to point messaging", aren't we already adding multiple outbound routes for http for delivering activities to individual subscribers? Perhaps I'm misunderstanding the architecture. From what I understand, the current architecture allows for an activity to be posted and stored on a single server and that message is sent to the same server via JMS (ActiveMQ). Are we talking about an architecture where all of these components (ActivityAggregator, SubscriberWarehouse, Registration) are all on separate servers? If that is the case, then I can understand the usage of ActiveMQ, but I don't understanding sending a message via JMS from one server to the same server.
> > Thanks!
> >
> > Danny
> >
> >> From: dsullivan7@hotmail.com
> >> To: dev@streams.incubator.apache.org
> >> Subject: RE: Use of ActiveMQ
> >> Date: Thu, 19 Sep 2013 16:19:42 -0400
> >>
> >> Good to know, thanks for the info!
> >>
> >> > Date: Thu, 19 Sep 2013 16:17:52 -0400
> >> > Subject: Re: Use of ActiveMQ
> >> > From: jletourneau80@gmail.com
> >> > To: dev@streams.incubator.apache.org
> >> >
> >> > Yeah that stuff too ;)
> >> >
> >> > On Thu, Sep 19, 2013 at 4:14 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> >> > > Failover, load_balancing......
> >> > >
> >> > >
> >> > > On Thu, Sep 19, 2013 at 1:13 PM, Jason Letourneau
> >> > > <jl...@gmail.com>wrote:
> >> > >
> >> > >> Performance more than anything for passing between components but also
> >> > >> for advanced messaging patterns or systems that might be interested in
> >> > >> wiretapping the JMS queues - http would lock us into point to point
> >> > >> messaging between all the components, though I guess you could just
> >> > >> add multiple outbound routes for http...
> >> > >>
> >> > >> On Thu, Sep 19, 2013 at 3:18 PM, Danny Sullivan <ds...@hotmail.com>
> >> > >> wrote:
> >> > >> > Hey Everyone,
> >> > >> > Is there a reason to use ActiveMQ in Streams at all? I noticed the
> >> > >> following in the streamsCamelContext.xml:
> >> > >> > <!--split activities on Q, waiting for aggregation --> <route>
> >> > >> <from uri="direct:activityQ"/> <inOnly
> >> > >> uri="activemq:queue:activities"/> </route>
> >> > >> > <route> <from uri="activemq:queue:activities"/>
> >> > >> <aggregate completionInterval="500" groupExchanges="true">
> >> > >> <correlationExpression> <constant>true</constant>
> >> > >> </correlationExpression> <bean
> >> > >> ref="activityService" method="receiveExchange"/> </aggregate>
> >> > >> </route>
> >> > >> >
> >> > >> > I replace this with the following and got the same functionality:
> >> > >> > <!--split activities on Q, waiting for aggregation --> <route>
> >> > >> <from uri="direct:activityQ"/> <aggregate
> >> > >> completionInterval="500" groupExchanges="true">
> >> > >> <correlationExpression> <constant>true</constant>
> >> > >> </correlationExpression> <bean
> >> > >> ref="activityService" method="receiveExchange"/> </aggregate>
> >> > >> </route>
> >> > >> > This makes sense conceptually because what we currently have is a POST
> >> > >> method reaching the server and being sent to the same server via JMS. Is
> >> > >> there a reason to use a messaging system rather than have the streams sent
> >> > >> and received via http? Either Camel or Spring MVC should be able to
> >> > >> accomplish this. What I'd like to do is set up single endpoints for
> >> > >> publisher registration, subscriber registration, publishing streams, and
> >> > >> receiving streams in Camel (because Storm unfortunately doesn't look like
> >> > >> it provides support for http routing). Storm would process all the data
> >> > >> coming in from Camel and output it to the Cassandra DB. Receiving streams
> >> > >> would operate much in the same way it currently does: by refreshing the
> >> > >> stream from the database.
> >> > >> > Danny
> >> > >>
> >>
> >