On Wed, Nov 16, 2011 at 10:37 AM, Claus Ibsen wrote:
> On Tue, Nov 15, 2011 at 4:52 PM, Preben.Asmussen wrote:
>> @Claus
>>
>> +1 This would be really helpfull.
>>
>> In addition to the problem you laid out I can tell that consuming 100 rows
>> -> processing the 70 building a xml payload -> put
On Tue, Nov 15, 2011 at 4:52 PM, Preben.Asmussen wrote:
> @Claus
>
> +1 This would be really helpfull.
>
> In addition to the problem you laid out I can tell that consuming 100 rows
> -> processing the 70 building a xml payload -> put in on a jms queue and
> then on the 71 have an error that rol
On Tue, Nov 15, 2011 at 6:59 PM, Preben.Asmussen wrote:
> @Claus
> Just had a look at commit
> http://svn.apache.org/viewvc/camel/trunk/components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java?p2=%2Fcamel%2Ftrunk%2Fcomponents%2Fcamel-jpa%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache
Yeah, that's exactly what I also doubted in my previous Post.
--
View this message in context:
http://camel.465427.n5.nabble.com/Misleading-jmx-statistics-on-jpa-component-tp4960503p4995364.html
Sent from the Camel - Users mailing list archive at Nabble.com.
@Claus
Just had a look at commit
http://svn.apache.org/viewvc/camel/trunk/components/camel-jpa/src/main/java/org/apache/camel/component/jpa/JpaConsumer.java?p2=%2Fcamel%2Ftrunk%2Fcomponents%2Fcamel-jpa%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fcamel%2Fcomponent%2Fjpa%2FJpaConsumer.java&p1=%2Fcamel%2Ftr
@Claus,
That's for sure may be not correct, but it's how I see it:
To my understanding in the sense of the CRUD operation one can C, U or D an
entity through the JpaProducer, however
only R through a JpaConsumer, so don't get the point why JpaConsumer should
do entityManager.flush() at all, for
e
@Claus
+1 This would be really helpfull.
In addition to the problem you laid out I can tell that consuming 100 rows
-> processing the 70 building a xml payload -> put in on a jms queue and
then on the 71 have an error that rolles everything back ultimately can fill
up the redolog off the db and
Claus,
cool thanx :)
regards, Achim
2011/11/15 Claus Ibsen
> On Tue, Nov 15, 2011 at 11:05 AM, Claus Ibsen
> wrote:
> > On Tue, Nov 15, 2011 at 11:02 AM, Achim Nierbeck
> > wrote:
> >> Hi Clause,
> >>
> >> even though I'm fully with you that this sounds reasonable I would like
> to
> >> see
On Tue, Nov 15, 2011 at 11:05 AM, Claus Ibsen wrote:
> On Tue, Nov 15, 2011 at 11:02 AM, Achim Nierbeck
> wrote:
>> Hi Clause,
>>
>> even though I'm fully with you that this sounds reasonable I would like to
>> see this
>> feature/improvement optional or at least being able to be disabled since
>
Hi Claus,
just saw your proposal and would like to share my idea as well but please
let me get back to you today afternoon (UTC/GMT +1 hour)
in the meanwhile in the case you would have some spare time (which I doubt
:-)) I would really appreciate if you would take a look at [1] to see if I
advise
On Tue, Nov 15, 2011 at 11:02 AM, Achim Nierbeck
wrote:
> Hi Clause,
>
> even though I'm fully with you that this sounds reasonable I would like to
> see this
> feature/improvement optional or at least being able to be disabled since
> right now
> I'm actually using this feature of a complete roll
Hi Clause,
even though I'm fully with you that this sounds reasonable I would like to
see this
feature/improvement optional or at least being able to be disabled since
right now
I'm actually using this feature of a complete rollback of all changes done,
because one of the
incoming messages is "cor
+1
That sounds good
Christian
Am 15.11.2011 10:26, schrieb Claus Ibsen:
Hi
The JPA consumer is a bit special as its consuming messages from a
database, as they were from a JMS queue.
So its basically a queue based solution on a database table.
So I frankly think we should alter the concept o
Hi
The JPA consumer is a bit special as its consuming messages from a
database, as they were from a JMS queue.
So its basically a queue based solution on a database table.
So I frankly think we should alter the concept of transaction, as IMHO
it does not make sense to consume X number of rows fro
@Claus,
could you also please take a quick look at my comment on the ticket as well:
https://issues.apache.org/jira/browse/CAMEL-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149180#comment-13149180
Thanks, Babak
--
View this message in context:
On Sat, Nov 12, 2011 at 2:03 PM, Preben.Asmussen wrote:
> Added comment to https://issues.apache.org/jira/browse/CAMEL-4668
>
> If the jmx stats. doesn't reflect that the exchanges have failed, then it
> would be hard to use the statistics for eg. monitoring tools.
>
Its not hard, the monitoring
Added comment to https://issues.apache.org/jira/browse/CAMEL-4668
If the jmx stats. doesn't reflect that the exchanges have failed, then it
would be hard to use the statistics for eg. monitoring tools.
--
View this message in context:
http://camel.465427.n5.nabble.com/Misleading-jmx-statistics-o
On Fri, Nov 4, 2011 at 7:21 PM, Preben.Asmussen wrote:
> It seems that there are at least 2 discussions going on here if I'm not
> wrong.
>
> That Spring tries to commit even though the transaction is marked for
> rollback, and that that the jmx statistics reflects completed on exchanges
> that ar
On Fri, Nov 4, 2011 at 7:21 PM, Preben.Asmussen wrote:
> It seems that there are at least 2 discussions going on here if I'm not
> wrong.
>
> That Spring tries to commit even though the transaction is marked for
> rollback, and that that the jmx statistics reflects completed on exchanges
> that ar
It seems that there are at least 2 discussions going on here if I'm not
wrong.
That Spring tries to commit even though the transaction is marked for
rollback, and that that the jmx statistics reflects completed on exchanges
that are rolled back.
At the end whole batch of 100 is rolled back, but
Yes I think that would help. Preben also suggested that it might be a
good idea to commit all rows before the exception so the one with the
error is the first one that fails next time. This avoids that you have
to retry all good records every time.
This may be a bit more difficult to achieve t
On Fri, Nov 4, 2011 at 10:57 AM, Christian Schneider
wrote:
> Well so it is code in spring that tries to commit. Still I would rather
> expect that the transaction should be rolled back.
>
Spring TX is weird. Even if you mark the TX for rollback only, it may
still commit it.
The solution is to th
Well so it is code in spring that tries to commit. Still I would rather
expect that the transaction should be rolled back.
Christian
Am 04.11.2011 10:24, schrieb bvahdat:
Hi Christian,
IMHO one can easily see that it's not camel trying to commit the transaction
(in contrast to what you claime
Hi Christian,
IMHO one can easily see that it's not camel trying to commit the transaction
(in contrast to what you claimed) but the current spring
PlatformTransactionManager in charge, in this given case it's spring
JpaTransactionManager, the relevant part by the stacktrace is:
...
at
org.spring
Hi Preben,
I am not so much concerned about the rollback but rather that camel
tries to commit.
The trace shows that the transaction is marked as rollback only. I guess
that happens because of the exception that is thrown.
I think camel should in this case roll back the transaction and not tr
Hi Christian
Here is a nice trace.
As you can see the whole batch is rolled back when redelivery gets
exhausted.
[rip.adapters.rap.PublicationIn] DefaultErrorHandlerWARN Failed
delivery for exchangeId: ID-W14523-2657-1320391149162-0-141. On delivery
attempt: 0 caught: java.lang.Ru
Hi Preben,
could you also post the log snippet where it shows that the transaction
is rollback only?
Christian
Am 03.11.2011 10:00, schrieb Preben.Asmussen:
Im using the jpa component as a consumer to poll a table. The batchsize of
each poll is set to eg. 100 as :
The route is transacted
27 matches
Mail list logo
