Unexpected behavior with splitter

2014-02-19 Thread BlackTie
I'm having an issue with split()... I'm tokenizing a large CSV file in streaming mode. Each line is used to create an object which is then sent as an in-only exchange to a JMS queue. If I don't turn on parallel processing, the split goes through the whole file and creates all the objects before s

Re: Unexpected behavior with splitter

2014-02-19 Thread BlackTie
Sure, here is the route: from("jms:queue:csv-request?maxConcurrentConsumers=1") .transacted("propagationRequired") .process(uriToFileProcessor) .split().tokenize("\n", 1).streaming().parallelProcessing().stopOnException().shareUnitOfWork() .choice().when(simple("${property.CamelSpli

Re: Unexpected behavior with splitter

2014-02-20 Thread BlackTie
Transactions do seem to be the reason it's behaving this way. I don't have much experience with transactions at this point, so I'm a bit ignorant on the subject. This may not be the correct place to go into detail about this, but I thought I read somewhere that the boundary of a transaction can't

Is there an alternative to request-reply when you want to use JMS transactions?

2014-02-20 Thread BlackTie
I currently have a route that take a message sent to a JMS queue, multicasts to some sub-queues, and then aggregates the resulting responses to return an overall status of processing to the client. This is working well using request-reply over JMS, but I would like to make the JMS queues transacti

Re: Is there an alternative to request-reply when you want to use JMS transactions?

2014-02-25 Thread BlackTie
I have implemented my proposed solution from my previous post, and it seems like it will work out. However, performing the aggregation in a separate route is a bit trickier than using an AggregationStrategy on the multicast or recipientList themselves. It doesn't look like any of the headers/prop

What is the best way to make a ProducerTemplate block on a condition?

2014-05-16 Thread BlackTie
Given that certain clients may want to make asynchronous requests or synchronous requests that return after a certain condition is met, and assuming that an initial request can result in many exchanges being processed over multiple routes, what is the best way to make the method using the producer

Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-16 Thread BlackTie
I have a webapp using Camel (v2.13.2) about to go into production, at the point of trying to tune things for performance. I'm having an issue with getting detail statistics for some routes, though. I'm using Hawtio 1.2, and for some routes, Hawtio is displaying the statistics for each processor i

Re: Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-17 Thread BlackTie
I am using hawtio as a standalone WAR, and did some research about accessing jolokia through hawtio. Browsing through the info that jolokia retrieves from JMX, not all the processors are listed. I added the maxObjects query param (with a value of 5000, which is higher than the number of beans we

Re: Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-20 Thread BlackTie
A mix of processors are missing... to, validate, multicast, log, etc... it seems like all the processors under some routes are missing. I haven't been able to figure out what the cause is. Can route syntax have an issue with statistics being gathered? Can transactions prevent statistics from be

Re: Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-23 Thread BlackTie
I tried configuring the JMX agent with registerAlways=true and that didn't make a difference. Still thinking about the transacted routes not being registered at the processor level in JMX, I removed the transacted method from the route builder for one of the routes that didn't have the detailed pr

Re: Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-24 Thread BlackTie
I don't have a small project that reproduces the issue, just the large app I'm performance-tuning now. I'm willing to try anything you recommend to figure out exactly what's wrong. I have a feeling that if I created a smaller project to mock this problem, I wouldn't be able to reproduce it. :) T

Re: Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-27 Thread BlackTie
Claus Ibsen-2 wrote > You can enable DEBUG logging for > org.apache.camel.management. And it should log when it enlists a > processor as MBean. Maybe you can see if the missing processors at > least is DEBUG logged. Claus, I enabled DEBUG for org.apache.camel.management as you requested. There i

Re: Not all processors are listed in JMX, preventing detailed route statistics/profiling

2014-10-28 Thread BlackTie
Charles Moulliard-2 wrote > Can you debug the project and add a breakpoint in this method (protected > boolean shouldRegister(Object service, Route route) {)) of this class > (org.apache.camel.management.DefaultManagementLifecycleStrategy) of > camel-core to see if the conditions are matched to re