On Mon, Jan 2, 2012 at 6:18 AM, ranjitkumarm wrote:
> Hi Christian,
>
> Thank you for you reply. I had already explored the second option
> you had suggested, but unfortunately it does not hold good for me, reason
> being the time of the SMSC server and and the machine on which my client
Hi
You have 2 slashes on the FTP starting path, eg you have //
ftp://u...@service.example.com//?
Is that on purpose?
On Thu, Dec 29, 2011 at 5:14 PM, David Wynter wrote:
> Sorry about that, web browser based email client, sometime I send it
> prematurely.
>
> Here is the trace from my ftp get
Hi
I have created a ticket and currently fixing the NPE
https://issues.apache.org/jira/browse/CAMEL-4850
On Mon, Jan 2, 2012 at 10:39 AM, Claus Ibsen wrote:
> Hi
>
> You have 2 slashes on the FTP starting path, eg you have //
> ftp://u...@service.example.com//?
>
> Is that on purpose?
>
>
> On
Hello,
I have route (camel 2.7.1):
ftp://user@host/folder?password=password&delete=true"; />
java.lang.Exception
If I don't have permissions to delete the remote file, the same file gets
processed and is put to activemq queue over and over again (onException
block d
Thanks, this was really helpful. I noticed however that the delay only worked
for the first retry, all subsequent retries would be handled immediately. I
solved this by resetting the scheduledJobId back to null just before sending
it back to the queue. My exception handler now looks like:
...
.onE
Hi
The OnException is handling exceptions as part of *routing* messages
in Camel routes.
There is a window in each consumer where exceptions can occur as well, that is
- before
- after
the Camel routing engine routes the message. If an exception occurs
before or after, then
its per consumer speci
Hello
I have implemented my own AggregationStrategy that aggregates messages based
on some business logic. The messages are read from a file before and routed
to my aggregator. This works pretty well so far.
Now I tested with some larger data sets and found that the performance of
the aggregation
wellafter some profiling (and reading the docs), I found an explanation
on my own:-)
The mock endpoints used in my unit test are the reason for the memory
increase. The mocks keep all messages in memory, just as it is documented. I
just did not see it in the docs.
So if I change my route to u
On Mon, Jan 2, 2012 at 4:42 PM, klauss42 wrote:
> wellafter some profiling (and reading the docs), I found an explanation
> on my own:-)
>
> The mock endpoints used in my unit test are the reason for the memory
> increase. The mocks keep all messages in memory, just as it is documented. I
> ju
