streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Letourneau <jletournea...@gmail.com>
Subject Re: Use of ActiveMQ
Date Tue, 01 Oct 2013 00:36:45 GMT
Yes - as a deployment decision, they could be on separate servers.

On Mon, Sep 30, 2013 at 9:31 AM, Danny Sullivan <dsullivan7@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 <chris@cxtsoftware.com> wrote:
>> > > Failover, load_balancing......
>> > >
>> > >
>> > > On Thu, Sep 19, 2013 at 1:13 PM, Jason Letourneau
>> > > <jletourneau80@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 <dsullivan7@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
>> > >>
>>
>

Mime
View raw message