thanks
On Thu, Jan 11, 2018 at 3:09 PM, Claus Ibsen wrote:
> Hi
>
> Yes its a little bug, its easier to reproduce if you make the
> processing slower, and speedup the file polling consumer to scan
> faster.
>
>
>
> On Tue, Jan 9, 2018 at 8:26 AM, Claus Ibsen wrote:
> > Hi
> >
> > Have patience,
Hi
Yes its a little bug, its easier to reproduce if you make the
processing slower, and speedup the file polling consumer to scan
faster.
On Tue, Jan 9, 2018 at 8:26 AM, Claus Ibsen wrote:
> Hi
>
> Have patience, we will take a look at this later when we get time.
>
>
>
> On Tue, Jan 9, 2018 a
Hi
Have patience, we will take a look at this later when we get time.
On Tue, Jan 9, 2018 at 1:52 AM, Bhuvan Gupta wrote:
> Humble request to validate my findings and confirming that it is a bug
>
> On 06-Jan-2018 5:06 PM, "Bhuvan Gupta" wrote:
>
> Camel Users,
>
> I have found the issue
> Fi
Humble request to validate my findings and confirming that it is a bug
On 06-Jan-2018 5:06 PM, "Bhuvan Gupta" wrote:
Camel Users,
I have found the issue
First lets go over the code routines that are executed for a route like
from("file:stageDummy")
.threads(1)
.process(myProcess)
Camel Users,
I have found the issue
First lets go over the code routines that are executed for a route like
from("file:stageDummy")
.threads(1)
.process(myProcess)
[1] In the above route there will be one polling thread (Let call it as "
*pollingThread*",) which poll the route dire
I suspect using “File consumer + threads(…) + default readLock” is like having
multiple File consumer watching the same folder - they’ll screw up each other.
I offer this as a possible proof: if you add an `idempotent=true` to your URI,
the problem should go away.
p/s: I think you’re trying
With TRUNCATED logs
[2.1] We can see that *"inside processornewFile887" *is printed first at
line 10 and then again at line 18
On Wed, Jan 3, 2018 at 8:39 PM, Bhuvan Gupta wrote:
> Hello,
>
> >>A typical problem is that your do some custom code where you read the
> >>file or do something with a
Hello,
>>A typical problem is that your do some custom code where you read the
>>file or do something with a input stream you do not close properly.
In the sample project shared our processor is doing nothing with file.
Here is the log attached.
Key Observations from log
[1] At end of the log I a
I am working more on it prove it.
meanwhile issue video
https://drive.google.com/file/d/1znGkVn2JtpFvtlUnwifPKCTWujAiFFPo/view
See @00.05
On Wed, Jan 3, 2018 at 7:26 PM, Claus Ibsen wrote:
> We cannot reproduce your problem.
>
> There can be several reasons why a file cannot be renamed, but
> u
We cannot reproduce your problem.
There can be several reasons why a file cannot be renamed, but
unfortunately the file api just returns a boolean if it cannot rename
a file.
A typical problem is that your do some custom code where you read the
file or do something with a input stream you do not c
I have created a bug for it as we are able to see the same for Oracle 1.8
and 2.20.1 version as well
https://issues.apache.org/jira/browse/CAMEL-12112
Thanks
On Wed, Jan 3, 2018 at 10:27 AM, Bhuvan Gupta wrote:
> Onder,
>
> I am running camel in default mode. i.e
> [1] setup pom
> [2] run the
Onder,
I am running camel in default mode. i.e
[1] setup pom
[2] run the sample shared.
I am not doing any specific configuration
On Tue, Jan 2, 2018 at 8:38 PM, Onder SEZGIN wrote:
> hi, did you check default behaviour of file consumer depending on your
> environment and readLock option on th
hi, did you check default behaviour of file consumer depending on your
environment and readLock option on the endpoint as well?
On Tue, Jan 2, 2018 at 8:02 AM, Bhuvan Gupta wrote:
> Hello nice people,
>
> We are using camel 2.17 with java 1.7 in our sample project and we defined
> our route as:
13 matches
Mail list logo
