date:20151022

Re: Camel 2.15.3: multicast with aggregationStrategy() not working ...

2015-10-22 Thread Claus Ibsen

Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP is for the aggreagator
eip, not muilticast.

On Thu, Oct 22, 2015 at 8:15 PM, SteveR  wrote:
> I'm using Camel 2.15.3 with a route that reads from *netty4:udp* and
> multicasts to two SEDA queues and uses *aggregationStrategy()* to choose the
> correct response to send back to the client as the UDP reply.
>
> I can see the correct reply coming into the aggregate() method, but setting
> the *Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP* property on the returned
> exchange does not stop the aggregation.  Am I doing something wrong, or do
> we know of any bugs in the area?
>
>
> Thanks, SteveR
>
> @Override
> public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
>
> String newBody = newExchange.getIn().getBody(String.class);
> if(newBody.contains(CQMS_ACK_SUBSTRING)) {
>
> newExchange.getOut().setBody(newExchange.getIn().getBody(String.class));
>
> newExchange.getOut().setHeaders(newExchange.getIn().getHeaders());
>
> newExchange.setProperty(Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP, true);
> return newExchange;
> }
> return newExchange;
> }
>
>
> from(fromURI)
> .setExchangePattern(ExchangePattern.InOut)
> .routeId(sourceRouteId)
> .setProperty(Exchange.CHARSET_NAME,
> ExpressionBuilder.constantExpression(charsetName))
> .threads(threadPoolSize /*poolSize*/, threadPoolSize * 2 
> /*maxPoolSize*/)
> .threadName("threads_" + sourceRouteId)
> .callerRunsWhenRejected(true); // Hard-coded since we always 
> want this
> behavior!
> .multicast()
> .parallelProcessing()
> .aggregationStrategy(new 
> CqmsAckBackAggregationStrategy(ackBackRequired,
> charsetName))
> .to(firstToURIs);
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-2-15-3-multicast-with-aggregationStrategy-not-working-tp5772978.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition

Re: Camel 2.15.3: multicast (default is take the latest reply?)

2015-10-22 Thread Claus Ibsen

Maybe use wire tap instead to send the 1st seda, and a regular to for
the 2nd, then you dont need multicast.

On Thu, Oct 22, 2015 at 8:36 PM, SteveR  wrote:
> From  Apache Camel Multicast Examples
>    it
> states: /"The final output from the multicast is the the latest reply
> message and it discards any earlier replies. If you want a different
> aggregation strategy to include even other reply messages, you need to
> create your own AggregationStrategy."/
>
> I have a route with a multicast() to two SEDA queues and I am currently
> using an aggregationStrategy() to choose the correct response to send back
> to the client as the UDP reply.  But I'm unable to get it to work!
>
> My question is, in the above statement, does *latest reply* mean the
> chronologically last reply received, or that the multicast will wait for the
> reply from the last multicast destination specified in the associated route?
>
> If I know, a priori, which SEDA queue will produce the correct reply, what
> is the easiest way to configure a multicast with respect to aggregation?
> I'm hoping, in thissimple case of multicasting to only two SEDA queues that
> I can find a way that doesn't require a custom aggregationStrategy.
>
>   Thanks, SteveR
>
> Maybe something like this:
>
> from(netty4:udp ...)
> .setExchangePattern(ExchangePattern.InOut)
> .multicast()
> .parallelProcessing()
> .to(firstSEDAUri)
> .end()
> .to(secondSEDAUri)  // <--- This route will return the reply 
> that needs to
> be sent back to the client via netty4:udp.
> .end();
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-2-15-3-multicast-default-is-take-the-latest-reply-tp5772979.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition

Re: Java Standalone Application Stopped Automatically

2015-10-22 Thread yogu13

What do your application/camel logs say ?



--
View this message in context: 
http://camel.465427.n5.nabble.com/Java-Standalone-Application-Stopped-Automatically-tp5772974p5772982.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Camel 2.15.3: multicast (default is take the latest reply?)

2015-10-22 Thread SteveR

>From  Apache Camel Multicast Examples
   it
states: /"The final output from the multicast is the the latest reply
message and it discards any earlier replies. If you want a different
aggregation strategy to include even other reply messages, you need to
create your own AggregationStrategy."/

I have a route with a multicast() to two SEDA queues and I am currently
using an aggregationStrategy() to choose the correct response to send back
to the client as the UDP reply.  But I'm unable to get it to work!

My question is, in the above statement, does *latest reply* mean the
chronologically last reply received, or that the multicast will wait for the
reply from the last multicast destination specified in the associated route?

If I know, a priori, which SEDA queue will produce the correct reply, what
is the easiest way to configure a multicast with respect to aggregation? 
I'm hoping, in thissimple case of multicasting to only two SEDA queues that
I can find a way that doesn't require a custom aggregationStrategy.

  Thanks, SteveR

Maybe something like this:

from(netty4:udp ...)
.setExchangePattern(ExchangePattern.InOut)
.multicast()
.parallelProcessing()
.to(firstSEDAUri)
.end()
.to(secondSEDAUri)  // <--- This route will return the reply 
that needs to
be sent back to the client via netty4:udp.
.end();



--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-2-15-3-multicast-default-is-take-the-latest-reply-tp5772979.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Camel 2.15.3: multicast with aggregationStrategy() not working ...

2015-10-22 Thread SteveR

I'm using Camel 2.15.3 with a route that reads from *netty4:udp* and
multicasts to two SEDA queues and uses *aggregationStrategy()* to choose the
correct response to send back to the client as the UDP reply.

I can see the correct reply coming into the aggregate() method, but setting
the *Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP* property on the returned
exchange does not stop the aggregation.  Am I doing something wrong, or do
we know of any bugs in the area?


Thanks, SteveR

@Override
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {

String newBody = newExchange.getIn().getBody(String.class);
if(newBody.contains(CQMS_ACK_SUBSTRING)) {
   
newExchange.getOut().setBody(newExchange.getIn().getBody(String.class));
   
newExchange.getOut().setHeaders(newExchange.getIn().getHeaders());
   
newExchange.setProperty(Exchange.AGGREGATION_COMPLETE_CURRENT_GROUP, true);
return newExchange;
}
return newExchange;
}


from(fromURI)
.setExchangePattern(ExchangePattern.InOut)
.routeId(sourceRouteId)
.setProperty(Exchange.CHARSET_NAME,
ExpressionBuilder.constantExpression(charsetName))
.threads(threadPoolSize /*poolSize*/, threadPoolSize * 2 
/*maxPoolSize*/)
.threadName("threads_" + sourceRouteId)
.callerRunsWhenRejected(true); // Hard-coded since we always 
want this
behavior!
.multicast()
.parallelProcessing()
.aggregationStrategy(new 
CqmsAckBackAggregationStrategy(ackBackRequired,
charsetName))
.to(firstToURIs);  



--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-2-15-3-multicast-with-aggregationStrategy-not-working-tp5772978.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Possible bug with BeanInfo.introspect in 2.15.3 version

2015-10-22 Thread apara

I have created issue https://issues.apache.org/jira/browse/CAMEL-9243 with
some test code to demonstrate this regression in 2.15.3.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Possible-bug-with-BeanInfo-introspect-in-2-15-3-version-tp5772875p5772977.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Java Standalone Application Stopped Automatically

2015-10-22 Thread V4Vaithi

I have a standalone Java camel application (Spring Based) running in Unix
sever. Sometimes it is getting stopped automatically without anyone killing
the process manually. 

I verified nmon report for that that period all resources (CPU, Disk IO,
Ram) are well with in limits. To trace of exception as well in application. 

Is there any other reason camel shutdowns itself? or any Unix kernel process
is stopping the application? 

/*Note:* /Application shutting down Gracefully in all instances.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Java-Standalone-Application-Stopped-Automatically-tp5772974.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Jetty server startup warnings when using handlers in Rest DSL

2015-10-22 Thread Karts

Hi,

When I have my restConfiguration as follows:














When the app is starting, I'm finding the logs are as follows:

2015-10-22 10:06:07,381 [main   ] INFO  Server
- jetty-9.2.11.v20150529
2015-10-22 10:06:07,381 [main   ] WARN  AbstractHandler   
- No Server set for
org.apache.camel.component.jetty.JettyHttpComponent$1@9cb5843
2015-10-22 10:06:07,382 [main   ] INFO  ContextHandler
- Started o.e.j.s.ServletContextHandler@6c9edf18{/,null,AVAILABLE}
2015-10-22 10:06:07,382 [main   ] INFO  ServerConnector   
- Started ServerConnector@365fb621{HTTP/1.1}{0.0.0.0:8080}
2015-10-22 10:06:07,382 [main   ] INFO  Server
- Started @9985ms
2015-10-22 10:06:07,382 [main   ] INFO  SpringCamelContext
- Route: route-route1 started and consuming from:
Endpoint[jetty:http://0.0.0.0:8080/routes/route/route1?httpMethodRestrict=GET]
2015-10-22 10:06:07,413 [main   ] INFO  ServerConnector   
- Stopped ServerConnector@365fb621{HTTP/1.1}{0.0.0.0:8080}
2015-10-22 10:06:07,413 [main   ] INFO  ContextHandler
- Stopped o.e.j.s.ServletContextHandler@6c9edf18{/,null,UNAVAILABLE}
2015-10-22 10:06:07,413 [main   ] INFO  Server
- jetty-9.2.11.v20150529
2015-10-22 10:06:07,413 [main   ] WARN  AbstractHandler   
- No Server set for
org.apache.camel.component.jetty.JettyHttpComponent$1@9cb5843
2015-10-22 10:06:07,413 [main   ] INFO  ContextHandler
- Started o.e.j.s.ServletContextHandler@6c9edf18{/,null,AVAILABLE}
2015-10-22 10:06:07,429 [main   ] INFO  ServerConnector   
- Started ServerConnector@365fb621{HTTP/1.1}{0.0.0.0:8080}
2015-10-22 10:06:07,429 [main   ] INFO  Server
- Started @10032ms
2015-10-22 10:06:07,429 [main   ] INFO  SpringCamelContext
- Route: route-route2 started and consuming from:
Endpoint[jetty:http://0.0.0.0:8080/routes/route/route2?httpMethodRestrict=GET]
2015-10-22 10:06:07,429 [main   ] INFO  SpringCamelContext
- Total 2 routes, of which 2 is started.
2015-10-22 10:06:07,429 [main   ] INFO  SpringCamelContext
- Apache Camel 2.16.0 (CamelContext: routes) started in 0.921 seconds

It seems to work fine, but I'm not sure why we have the warnings and
stop/starts above.

If I do not include the handlers endPointProperty, it starts well:

2015-10-22 10:13:21,521 [main   ] INFO  Server
- jetty-9.2.11.v20150529
2015-10-22 10:13:21,521 [main   ] WARN  AbstractHandler   
- No Server set for
org.apache.camel.component.jetty.JettyHttpComponent$1@4d7f405e
2015-10-22 10:13:21,522 [main   ] INFO  ContextHandler
- Started o.e.j.s.ServletContextHandler@35926cb6{/,null,AVAILABLE}
2015-10-22 10:13:21,522 [main   ] INFO  ServerConnector   
- Started ServerConnector@51ebde29{HTTP/1.1}{0.0.0.0:8080}
2015-10-22 10:13:21,522 [main   ] INFO  Server
- Started @9554ms
2015-10-22 10:13:21,522 [main   ] INFO  SpringCamelContext
- Route: route-route1 started and consuming from:
Endpoint[jetty:http://0.0.0.0:8080/routes/route/route1?httpMethodRestrict=GET]
2015-10-22 10:13:21,553 [main   ] INFO  SpringCamelContext
- Route: route-route2 started and consuming from:
Endpoint[jetty:http://0.0.0.0:8080/routes/route/route2?httpMethodRestrict=GET]
2015-10-22 10:13:21,553 [main   ] INFO  SpringCamelContext
- Total 2 routes, of which 2 is started.




--
View this message in context: 
http://camel.465427.n5.nabble.com/Jetty-server-startup-warnings-when-using-handlers-in-Rest-DSL-tp5772973.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Rest DSL Jetty multiple handlers causes java.lang.StackOverflowError

2015-10-22 Thread Karts

This seems similar to https://issues.jboss.org/browse/ENTESB-2619 

Also for brevity, below are the two handler beans:


   
   
   



   
   



   
  
   
   
  
   
   
  
 
  
   














--
View this message in context: 
http://camel.465427.n5.nabble.com/Rest-DSL-Jetty-multiple-handlers-causes-java-lang-StackOverflowError-tp5772952p5772972.html
Sent from the Camel - Users mailing list archive at Nabble.com.

How to log the messages for enrich

2015-10-22 Thread kumar

HI , 

I have route with enrich to communicate with host in soap message format.
but how can i log the outgoing / incoming messages of soap using spring dsl.

Thanks,
Kumar



--
View this message in context: 
http://camel.465427.n5.nabble.com/How-to-log-the-messages-for-enrich-tp5772970.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: AllowUseOriginalMessage do i need it?

2015-10-22 Thread Claus Ibsen

No

Its only if you call the getOriginalMessage method or have configured
the error handler to use the original message when it moves messages
to a DLQ etc.



On Thu, Oct 22, 2015 at 2:19 PM, dermoritz  wrote:
> I am not sure about
> "AllowUseOriginalMessage is enabled. If access to the original message is
> not needed, then its recommended to turn this option off as it may improve
> performance."
>
> In my route the original message is not used in error handler but i attached
> a RoutePolicy that implements onExchangeDone to stop.
> If i understood right this is called only on the original message.
>
> This is the beginning of my route:
>
> from( trigger )
> .routePolicy( new FinishNotifier( onFinsh ) )
> .to( in ).split().body()
> .streaming()
>
> The original message is a very long stream from data base.
>
> Do i need "AllowUseOriginalMessage" to be enabled.
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/AllowUseOriginalMessage-do-i-need-it-tp5772968.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2nd edition:
https://www.manning.com/books/camel-in-action-second-edition

AllowUseOriginalMessage do i need it?

2015-10-22 Thread dermoritz

I am not sure about
"AllowUseOriginalMessage is enabled. If access to the original message is
not needed, then its recommended to turn this option off as it may improve
performance."

In my route the original message is not used in error handler but i attached
a RoutePolicy that implements onExchangeDone to stop.
If i understood right this is called only on the original message. 

This is the beginning of my route:

from( trigger )
.routePolicy( new FinishNotifier( onFinsh ) )
.to( in ).split().body()
.streaming()

The original message is a very long stream from data base.

Do i need "AllowUseOriginalMessage" to be enabled.



--
View this message in context: 
http://camel.465427.n5.nabble.com/AllowUseOriginalMessage-do-i-need-it-tp5772968.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Advice needed - throttling jms producing

2015-10-22 Thread David Karlsen

Usecase:

I have a route which ends with sending to a jms queue.
OutOnly - no req/res.

In order to avoid producing too fast I want to throttle the production
rate based on queue depth (or ratio of max queue depth).

I have api's to query the queuedepth.

I've been looking at http://camel.apache.org/throttler.html which
seems most suitable.
I can implement the maximumRequestsPerPeriod as a custom expression
which queries the messaging subsystem, and thus return a number of
messages "left" (e.g. maxdepth-currentdepth). I can further optimize
this a bit by caching the counting to every n-th invocation or
timewindow of 10 sec or so (so I don't query the mom for each and
every message -> overhead).

However it's not possible to "block entirely" by returning 0.

Of course I'm pretty close if returning 1 - which is probably a
situation we'll never get into anyway - as long as the consumer of
messages of the queue is in fact alive and able to process.

Anybody else done this? Seems like common usecase. Should it be
possible to return 0 in the expression and thereby block the route
completely?

-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Re: Camel 2.15.3: multicast with aggregationStrategy() not working ...

Re: Camel 2.15.3: multicast (default is take the latest reply?)

Re: Java Standalone Application Stopped Automatically

Camel 2.15.3: multicast (default is take the latest reply?)

Camel 2.15.3: multicast with aggregationStrategy() not working ...

Re: Possible bug with BeanInfo.introspect in 2.15.3 version

Java Standalone Application Stopped Automatically

Jetty server startup warnings when using handlers in Rest DSL

Re: Rest DSL Jetty multiple handlers causes java.lang.StackOverflowError

How to log the messages for enrich

Re: AllowUseOriginalMessage do i need it?

AllowUseOriginalMessage do i need it?

Advice needed - throttling jms producing

13 matches

Site Navigation

Mail list logo

Footer information