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
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.
>
>
>
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:
>
>
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)
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
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
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
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
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
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]
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
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
13 matches
Mail list logo