streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Sullivan <dsulliv...@hotmail.com>
Subject RE: Use of ActiveMQ
Date Tue, 01 Oct 2013 01:29:37 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message