[jira] [Created] (CAMEL-20728) camel-aws2s3 Stream Producer should support multipart loading

[Benjamin BONNET (Jira)]

Benjamin BONNET created CAMEL-20728:
---

 Summary: camel-aws2s3 Stream Producer should support multipart 
loading
 Key: CAMEL-20728
 URL: https://issues.apache.org/jira/browse/CAMEL-20728
 Project: Camel
  Issue Type: New Feature
  Components: camel-aws
Affects Versions: 4.5.0
Reporter: Benjamin BONNET


AWS2S3 Producer comes in two flavours: AWS2S3Producer and 
AWS2S3StreamUploadProducer.
 * AWS2S3Producer  supports S3 multipart upload: exchange data will be chunked 
into parts, parts will be sent separately  to S3 and will be aggregated into 
one file.
 * AWS2S3StreamUploadProducer supports message streaming: incoming messages are 
aggregated into a buffer that will be sent as one file to S3, as soon as some 
condition is true (number of messages / size /timeout).

Unfortunately, AWS2S3StreamUploadProducer, although it is able to break a huge 
flow of messages into parts (which is great for some use cases), is not able to 
manage S3 multipart upload. So if you need to aggregate lots of messages into 
one big file on S3 side, that means the producer will have to send that message 
batch in one request (actually, a single part multipart request if you look at 
implementation). If the volume is huge, that will blow up jvm heap.

So we propose to add multi-part support to  AWS2S3StreamUploadProducer.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-17613) camel-sql - Race condition in AggregateProcessor with Jdbc Repository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517446#comment-17517446
 ] 

Benjamin BONNET commented on CAMEL-17613:
-

Hi,

I have made a unit test that shows how transactions might execute in reverse 
order.

See [https://github.com/bonnetb/camel/tree/CAMEL-17613,]  (commit 
[https://github.com/bonnetb/camel/commit/4da7abe5543434cba48f3e0f7f0a1d7fdb160462]).

This test uses an Atomikos transaction manager and an XA datasource (H2). By 
extending Atomikos transaction manager, I added some delay at commit time for 
the transaction that should occur first. As a result, the other transaction 
(DELETE) occurs first and you may see an ERROR log "DELETE statement did not 
return 1 but 0".

I noticed you set 3.17.0 as fix version : have you already worked on a fix ?

 

> camel-sql - Race condition in AggregateProcessor with Jdbc Repository
> -
>
> Key: CAMEL-17613
> URL: https://issues.apache.org/jira/browse/CAMEL-17613
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-sql
>Affects Versions: 3.11.2
>Reporter: Benjamin BONNET
>Priority: Major
> Fix For: 3.17.0
>
> Attachments: CAMEL-17613-log.txt, Spring_jdbc_transactions.log
>
>
> Hi,
> using aggregate with a JdbcAggregationRepository, we are encountering a race 
> condition that may leave a completed exchange in completed table even after 
> that completed exchange has been sent. Unfortunately, that leads to 
> duplicates since recovery task will eventually try and recover it.
> Normally, when the exchange completes, it is deleted from repo exchange table 
> and inserted into repo completed exchange table. Then exchange is sent and 
> deleted from repo completed exchange table.
> But, due to the fact those two actions are run by different threads (and in 
> different transactions) that order may vary.
>  
> Here is a normal sequence : 
> AggregateProcessor.doProcess
>   doAggregation
>     doAggregationComplete
>       onCompletion
>         JdbcAggregationRepository.remove : => INSERT ... INTO _completed  
>   onSubmitCompletion  
>     AggregateOnCompletion.onComplete   (via executorService)
>       JdbcAggregationRepository.confirm  : => DELETE FROM _completed
> With the use of executorService, confirm is run by another thread and may 
> commit before remove commits. Eventually, when that occurs, one can check 
> that DELETE statement returns 0 (number of deleted rows) instead of 1.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17613) camel-sql - Race condition in AggregateProcessor with Jdbc Repository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490737#comment-17490737
 ] 

Benjamin BONNET commented on CAMEL-17613:
-

[~klease78], isolation level  is implicitly set to PostgreSQL default isolation 
level : Read Committed. Propagation behaviour is explicitly set to 
PROPAGATION_REQUIRED.

> camel-sql - Race condition in AggregateProcessor with Jdbc Repository
> -
>
> Key: CAMEL-17613
> URL: https://issues.apache.org/jira/browse/CAMEL-17613
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-sql
>Affects Versions: 3.11.2
>Reporter: Benjamin BONNET
>Priority: Major
> Fix For: 3.16.0
>
> Attachments: CAMEL-17613-log.txt
>
>
> Hi,
> using aggregate with a JdbcAggregationRepository, we are encountering a race 
> condition that may leave a completed exchange in completed table even after 
> that completed exchange has been sent. Unfortunately, that leads to 
> duplicates since recovery task will eventually try and recover it.
> Normally, when the exchange completes, it is deleted from repo exchange table 
> and inserted into repo completed exchange table. Then exchange is sent and 
> deleted from repo completed exchange table.
> But, due to the fact those two actions are run by different threads (and in 
> different transactions) that order may vary.
>  
> Here is a normal sequence : 
> AggregateProcessor.doProcess
>   doAggregation
>     doAggregationComplete
>       onCompletion
>         JdbcAggregationRepository.remove : => INSERT ... INTO _completed  
>   onSubmitCompletion  
>     AggregateOnCompletion.onComplete   (via executorService)
>       JdbcAggregationRepository.confirm  : => DELETE FROM _completed
> With the use of executorService, confirm is run by another thread and may 
> commit before remove commits. Eventually, when that occurs, one can check 
> that DELETE statement returns 0 (number of deleted rows) instead of 1.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-17613) camel-sql - Race condition in AggregateProcessor with Jdbc Repository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490229#comment-17490229
 ] 

Benjamin BONNET commented on CAMEL-17613:
-

I could not isolate the issue in a unit test, but here is an execution log 
extract (I added some debug log after insert and delete 
statement):[^CAMEL-17613-log.txt]

According to log, INSERT occurs before DELETE, but when DELETE is executed, row 
is not yet visible. I wonder how it is possible :
 * transactions are run very close one with each other, probably using 
different JDBC connections. The DB (PostgreSQL) guarantees isolation, but I am 
not sure order is guaranteed too.
 * we are using XA transactions (with Atomikos as a transaction manager) and we 
have to check that it does not add asynchronee somewhere on commit path.

 

> camel-sql - Race condition in AggregateProcessor with Jdbc Repository
> -
>
> Key: CAMEL-17613
> URL: https://issues.apache.org/jira/browse/CAMEL-17613
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-sql
>Affects Versions: 3.11.2
>Reporter: Benjamin BONNET
>Priority: Major
> Fix For: 3.16.0
>
> Attachments: CAMEL-17613-log.txt
>
>
> Hi,
> using aggregate with a JdbcAggregationRepository, we are encountering a race 
> condition that may leave a completed exchange in completed table even after 
> that completed exchange has been sent. Unfortunately, that leads to 
> duplicates since recovery task will eventually try and recover it.
> Normally, when the exchange completes, it is deleted from repo exchange table 
> and inserted into repo completed exchange table. Then exchange is sent and 
> deleted from repo completed exchange table.
> But, due to the fact those two actions are run by different threads (and in 
> different transactions) that order may vary.
>  
> Here is a normal sequence : 
> AggregateProcessor.doProcess
>   doAggregation
>     doAggregationComplete
>       onCompletion
>         JdbcAggregationRepository.remove : => INSERT ... INTO _completed  
>   onSubmitCompletion  
>     AggregateOnCompletion.onComplete   (via executorService)
>       JdbcAggregationRepository.confirm  : => DELETE FROM _completed
> With the use of executorService, confirm is run by another thread and may 
> commit before remove commits. Eventually, when that occurs, one can check 
> that DELETE statement returns 0 (number of deleted rows) instead of 1.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17613) camel-sql - Race condition in AggregateProcessor with Jdbc Repository

[Benjamin BONNET (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET updated CAMEL-17613:

Attachment: CAMEL-17613-log.txt

> camel-sql - Race condition in AggregateProcessor with Jdbc Repository
> -
>
> Key: CAMEL-17613
> URL: https://issues.apache.org/jira/browse/CAMEL-17613
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-sql
>Affects Versions: 3.11.2
>Reporter: Benjamin BONNET
>Priority: Major
> Fix For: 3.16.0
>
> Attachments: CAMEL-17613-log.txt
>
>
> Hi,
> using aggregate with a JdbcAggregationRepository, we are encountering a race 
> condition that may leave a completed exchange in completed table even after 
> that completed exchange has been sent. Unfortunately, that leads to 
> duplicates since recovery task will eventually try and recover it.
> Normally, when the exchange completes, it is deleted from repo exchange table 
> and inserted into repo completed exchange table. Then exchange is sent and 
> deleted from repo completed exchange table.
> But, due to the fact those two actions are run by different threads (and in 
> different transactions) that order may vary.
>  
> Here is a normal sequence : 
> AggregateProcessor.doProcess
>   doAggregation
>     doAggregationComplete
>       onCompletion
>         JdbcAggregationRepository.remove : => INSERT ... INTO _completed  
>   onSubmitCompletion  
>     AggregateOnCompletion.onComplete   (via executorService)
>       JdbcAggregationRepository.confirm  : => DELETE FROM _completed
> With the use of executorService, confirm is run by another thread and may 
> commit before remove commits. Eventually, when that occurs, one can check 
> that DELETE statement returns 0 (number of deleted rows) instead of 1.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17616) JdbcAggregationRepository will not start if it contains too many exchanges

[Benjamin BONNET (Jira)]

Benjamin BONNET created CAMEL-17616:
---

 Summary: JdbcAggregationRepository will not start if it contains 
too many exchanges 
 Key: CAMEL-17616
 URL: https://issues.apache.org/jira/browse/CAMEL-17616
 Project: Camel
  Issue Type: Bug
  Components: camel-sql
Affects Versions: 3.11.2
Reporter: Benjamin BONNET


Hi,

We are using a JdbcAggregationRepository with a transactional Datasource. When 
JdbcAggregationRepository is started, if its table contains lots of rows, a 
transaction timeout may occur and make it fail to start.

Actually, when repo starts, doStart method is invoked, that method calls 
getKeys() and iterates over every row in order to count them, which may be 
quite long if repo contains millions of rows. 

In order to avoid that issue, count could be implemented directly in the SQL 
query.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (CAMEL-17613) Race condition in AggregateProcessor with Jdbc Repository

[Benjamin BONNET (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET updated CAMEL-17613:

Affects Version/s: 3.11.2
   (was: 3.11.4)

> Race condition in AggregateProcessor with Jdbc Repository
> -
>
> Key: CAMEL-17613
> URL: https://issues.apache.org/jira/browse/CAMEL-17613
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core, camel-sql
>Affects Versions: 3.11.2
>Reporter: Benjamin BONNET
>Priority: Major
>
> Hi,
> using aggregate with a JdbcAggregationRepository, we are encountering a race 
> condition that may leave a completed exchange in completed table even after 
> that completed exchange has been sent. Unfortunately, that leads to 
> duplicates since recovery task will eventually try and recover it.
> Normally, when the exchange completes, it is deleted from repo exchange table 
> and inserted into repo completed exchange table. Then exchange is sent and 
> deleted from repo completed exchange table.
> But, due to the fact those two actions are run by different threads (and in 
> different transactions) that order may vary.
>  
> Here is a normal sequence : 
> AggregateProcessor.doProcess
>   doAggregation
>     doAggregationComplete
>       onCompletion
>         JdbcAggregationRepository.remove : => INSERT ... INTO _completed  
>   onSubmitCompletion  
>     AggregateOnCompletion.onComplete   (via executorService)
>       JdbcAggregationRepository.confirm  : => DELETE FROM _completed
> With the use of executorService, confirm is run by another thread and may 
> commit before remove commits. Eventually, when that occurs, one can check 
> that DELETE statement returns 0 (number of deleted rows) instead of 1.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17613) Race condition in AggregateProcessor with Jdbc Repository

[Benjamin BONNET (Jira)]

Benjamin BONNET created CAMEL-17613:
---

 Summary: Race condition in AggregateProcessor with Jdbc Repository
 Key: CAMEL-17613
 URL: https://issues.apache.org/jira/browse/CAMEL-17613
 Project: Camel
  Issue Type: Bug
  Components: camel-core, camel-sql
Affects Versions: 3.11.4
Reporter: Benjamin BONNET


Hi,

using aggregate with a JdbcAggregationRepository, we are encountering a race 
condition that may leave a completed exchange in completed table even after 
that completed exchange has been sent. Unfortunately, that leads to duplicates 
since recovery task will eventually try and recover it.

Normally, when the exchange completes, it is deleted from repo exchange table 
and inserted into repo completed exchange table. Then exchange is sent and 
deleted from repo completed exchange table.

But, due to the fact those two actions are run by different threads (and in 
different transactions) that order may vary.

 

Here is a normal sequence : 

AggregateProcessor.doProcess
  doAggregation
    doAggregationComplete
      onCompletion
        JdbcAggregationRepository.remove : => INSERT ... INTO _completed  
  onSubmitCompletion  
    AggregateOnCompletion.onComplete   (via executorService)
      JdbcAggregationRepository.confirm  : => DELETE FROM _completed

With the use of executorService, confirm is run by another thread and may 
commit before remove commits. Eventually, when that occurs, one can check that 
DELETE statement returns 0 (number of deleted rows) instead of 1.

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-6097) Race condition in AggregatorProcessor recovery sometimes causes duplicates

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482358#comment-17482358
 ] 

Benjamin BONNET commented on CAMEL-6097:


Hi,

we have still a race condition between recover and aggregate threads on camel 
3.x.
In AggregateProcessor, recover task :
 # takes a picture of in progress completed exchanges
 # scans completed repo
 # recovers any completed exchange from 2 that is not in picture from 1 ant 
that is not in progress

So, if a exchange becomes completed after 1 and is dealt by aggregate thread 
between 2 and 3 , then it will be considered as completed and not in progress, 
and recovery task will recover it.

> Race condition in AggregatorProcessor recovery sometimes causes duplicates
> --
>
> Key: CAMEL-6097
> URL: https://issues.apache.org/jira/browse/CAMEL-6097
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.9.2
>Reporter: Benjamin Truitt
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.9.6, 2.10.5, 2.11.0
>
>
> There seems to be a race condition in 
> org.apache.camel.processor.aggregate.AggregateProcessor's RecoverTask.  That 
> task calls recoverable.scan() to find Exchanges that may need to be 
> recovered. Since scan() might return Exchanges that are actually just in 
> progress, the RecoverTask then checks to see if the Exchange really is in 
> progress.  It does this by calling 
> inProgressCompleteExchanges.contains(exchangeId).  However, that collection 
> may have been modified during the time between when scan() returned and when 
> contains() is called.  This would happen if the in-progress Exchange 
> completes before contains() is called.  In that situation, inProgress would 
> evaluate to false, so the Exchange would be recovered.  This results in a 
> duplicate Exchange being output by the Aggregator component. 
> One possible solution might be to prevent updating the 
> inProgressCompleteExchanges during the critical section. Another possible 
> solution might be to copy inProgressCompleteExchanges before calling scan().  
> I'm sure that there are other ways to deal with this also.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (CAMEL-4271) jdbc aggregation repository - recovery taks and cluster issue

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478996#comment-17478996
 ] 

Benjamin BONNET commented on CAMEL-4271:


Race condition may not only happen between multiple nodes recovery task, but it 
may also happen between a recovery task on one node and another node dealing 
with a newly complete exchange. 
As a matter of fact, a newly complete exchange, completed on node 'A', may look 
like an 'orphan' complete exchange on another node 'B' (node 'B' will see it as 
a complete exchange that is not in progress since node 'B' is not responsible 
for its completion). So, recovery task on that node 'B' may recover this 
exchange while node 'A' deals with it. That leads to duplication.
We are facing that issue with a JDBCAggregateRepository on camel 3.11

> jdbc aggregation repository - recovery taks and cluster issue
> -
>
> Key: CAMEL-4271
> URL: https://issues.apache.org/jira/browse/CAMEL-4271
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-sql
>Affects Versions: 2.8.0
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: Future
>
>
> If you enable recovery on the aggregator eip when using a persistent 
> repository such as the jdbc, then you may have a race condition when having 
> multiple camel apps running in a cluster. As the aggregate recover task is 
> running on each Camel app (node) in the cluster. So they may potentially all 
> pickup recovery tasks, and execute those, which may cause duplicate messages 
> being recovered.
> What is needed is a lock table or some other way to ensure only one recover 
> tasks "wins" and executes.
> We may want to enhance the API in camel to facilitate this kind of locking. 
> As with hawtdb you may have a shared file on the SAN and thus have the same 
> racing issue.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (CAMEL-17157) AggregateProcessor, TimeoutMap Restoration and Cluster

[Benjamin BONNET (Jira)]

Benjamin BONNET created CAMEL-17157:
---

 Summary: AggregateProcessor, TimeoutMap Restoration and Cluster
 Key: CAMEL-17157
 URL: https://issues.apache.org/jira/browse/CAMEL-17157
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 3.12.0, 3.11.3
Reporter: Benjamin BONNET


Hi,
Consider an aggregate having completion timeout and backed by a persistent 
repository (e.g. JBCAggregationRepository). When route starts, there is an 
invocation to restoreTimeoutMapFromAggregationRepositonry()  
(AggregatorProcessor, line 877). That method consists in :
# getting all keys of pending aggregations (i.e. aggregation that were not yet 
completed when route stopped)
# iterate on each key to get each row and put row timeout into timeoutmap.
That works fine when there is only one instance, but if you deploy on a 
cluster, things may go wrong.
As a matter of fact, if one instance is warming-up while another is modifying 
repository, warm-up may fail (NullPointerException) : that occurs when a row 
has been deleted (because aggregation was completed by a running instance) 
between 1. and 2. 
One can imagine another less noisy failure : a row is created by a running 
instance between 1. and 2. . Then warming-up does not complain, but the new row 
will not be included in timeout map, which may be an issue if the instance that 
inserted that row into the repo is stopped before completion (timeout will not 
be detected).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (CAMEL-15723) NPE when using PostgresAggregationRepository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437261#comment-17437261
 ] 

Benjamin BONNET edited comment on CAMEL-15723 at 11/2/21, 10:18 AM:


Hi,

We reproduced that issue on a heavy-loaded karaf with camel 3.11.2. This time, 
our aggregate has its own table. It is configured with optimistickLocking=true


It seems that there is a race condition that occurs with optimisticLock when 
two exchanges with same correlation Id are processed at the same time and when 
the aggregator does not already contain an aggregation with that correlation Id.


How it occurs ? 
Take 2 threads Th1 an Th2 having exchange1 and exchange2, with same 
correlationId key. If the following sequence occurs, you get a 
NullPointerException at line 171.


Th1 : invokes doAggregation(key, exchange1) on aggregate processor     
(AggregateProcessor line 477)
Th1 : invokes get(key) on repo   (AggregateProcessor line 484) => returns null
Th2 : invokes doAggregation(key, echange2) - that is possible since there is no 
lock
Th2 : invokes get(key) on repo => returns null and exchange 
CamelOptimisitcLockVersion remains not set  
Th1 : invokes add on repo (JdbcAggregationRepository line 152) => insert OK 
since no line with that key is "present"
Th2 : invokes add on repo => one line is present (the one added by Th1), but 
exchange2.getProp (CamelOptimistickLockversion) is null, which makes that 
NullPointerException at line 171


was (Author: bbonnet):
Hi,

We reproduced that issue on a heavy-loaded karaf. This time, our aggregate has 
its own table. It is configured with optimistickLocking=true


It seems that there is a race condition that occurs with optimisticLock when 
two exchanges with same correlation Id are processed at the same time and when 
the aggregator does not already contain an aggregation with that correlation Id.


How it occurs ? 
Take 2 threads Th1 an Th2 having exchange1 and exchange2, with same 
correlationId key. If the following sequence occurs, you get a 
NullPointerException at line 171.


Th1 : invokes doAggregation(key, exchange1) on aggregate processor     
(AggregateProcessor line 477)
Th1 : invokes get(key) on repo   (AggregateProcessor line 484) => returns null
Th2 : invokes doAggregation(key, echange2) - that is possible since there is no 
lock
Th2 : invokes get(key) on repo => returns null and exchange 
CamelOptimisitcLockVersion remains not set  
Th1 : invokes add on repo (JdbcAggregationRepository line 152) => insert OK 
since no line with that key is "present"
Th2 : invokes add on repo => one line is present (the one added by Th1), but 
exchange2.getProp (CamelOptimistickLockversion) is null, which makes that 
NullPointerException at line 171

> NPE when using PostgresAggregationRepository
> 
>
> Key: CAMEL-15723
> URL: https://issues.apache.org/jira/browse/CAMEL-15723
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.4.2
> Environment: * Apache Camel 3.4.2
>  * Spring Boot 2.3.4.RELEASE
>  * Postgres database as an aggregate repository
>Reporter: Corina Roman
>Priority: Major
> Fix For: 3.x
>
>
> Hi,
> we are getting production errors (NPE) when using a Postgres aggregate 
> repository and Camel code attempts to write to that table (under concurrent 
> use):
> {noformat}
> org.apache.camel.RuntimeCamelException: java.lang.RuntimeException: Error 
> adding to repository lb_data_uploads with key *** at 
> org.apache.camel.RuntimeCamelException.wrapRuntimeCamelException(RuntimeCamelException.java:52)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:142)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregationRepositoryAdd(AggregateProcessor.java:644)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:598)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:406)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doInOptimisticLock(AggregateProcessor.java:372)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:362)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:320)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:702)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:616)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
>  at 
> 

[jira] [Commented] (CAMEL-15723) NPE when using PostgresAggregationRepository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437261#comment-17437261
 ] 

Benjamin BONNET commented on CAMEL-15723:
-

Hi,

We reproduced that issue on a heavy-loaded karaf. This time, our aggregate has 
its own table. It is configured with optimistickLocking=true


It seems that there is a race condition that occurs with optimisticLock when 
two exchanges with same correlation Id are processed at the same time and when 
the aggregator does not already contain an aggregation with that correlation Id.


How it occurs ? 
Take 2 threads Th1 an Th2 having exchange1 and exchange2, with same 
correlationId key. If the following sequence occurs, you get a 
NullPointerException at line 171.


Th1 : invokes doAggregation(key, exchange1) on aggregate processor     
(AggregateProcessor line 477)
Th1 : invokes get(key) on repo   (AggregateProcessor line 484) => returns null
Th2 : invokes doAggregation(key, echange2) - that is possible since there is no 
lock
Th2 : invokes get(key) on repo => returns null and exchange 
CamelOptimisitcLockVersion remains not set  
Th1 : invokes add on repo (JdbcAggregationRepository line 152) => insert OK 
since no line with that key is "present"
Th2 : invokes add on repo => one line is present (the one added by Th1), but 
exchange2.getProp (CamelOptimistickLockversion) is null, which makes that 
NullPointerException at line 171

> NPE when using PostgresAggregationRepository
> 
>
> Key: CAMEL-15723
> URL: https://issues.apache.org/jira/browse/CAMEL-15723
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.4.2
> Environment: * Apache Camel 3.4.2
>  * Spring Boot 2.3.4.RELEASE
>  * Postgres database as an aggregate repository
>Reporter: Corina Roman
>Priority: Major
> Fix For: 3.x
>
>
> Hi,
> we are getting production errors (NPE) when using a Postgres aggregate 
> repository and Camel code attempts to write to that table (under concurrent 
> use):
> {noformat}
> org.apache.camel.RuntimeCamelException: java.lang.RuntimeException: Error 
> adding to repository lb_data_uploads with key *** at 
> org.apache.camel.RuntimeCamelException.wrapRuntimeCamelException(RuntimeCamelException.java:52)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:142)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregationRepositoryAdd(AggregateProcessor.java:644)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:598)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:406)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doInOptimisticLock(AggregateProcessor.java:372)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:362)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:320)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:702)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:616)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
>  at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:40)
>  at 
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.doRun(KafkaConsumer.java:346)
>  at 
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.run(KafkaConsumer.java:222)
>  at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  at java.base/java.lang.Thread.run(Thread.java:834) Caused by: 
> java.lang.RuntimeException: Error adding to repository lb_data_uploads with 
> key *** at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:176)
>  at 
> 

[jira] [Commented] (CAMEL-15723) NPE when using PostgresAggregationRepository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17390578#comment-17390578
 ] 

Benjamin BONNET commented on CAMEL-15723:
-

I would rather suspect exchange to be null.

We may have an explanation : we have 2 JdbcAggregationRepositories persisting 
data into the same pair of tables. We need to fix that and go on investigating. 
 

> NPE when using PostgresAggregationRepository
> 
>
> Key: CAMEL-15723
> URL: https://issues.apache.org/jira/browse/CAMEL-15723
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.4.2
> Environment: * Apache Camel 3.4.2
>  * Spring Boot 2.3.4.RELEASE
>  * Postgres database as an aggregate repository
>Reporter: Corina Roman
>Priority: Major
> Fix For: 3.x
>
>
> Hi,
> we are getting production errors (NPE) when using a Postgres aggregate 
> repository and Camel code attempts to write to that table (under concurrent 
> use):
> {noformat}
> org.apache.camel.RuntimeCamelException: java.lang.RuntimeException: Error 
> adding to repository lb_data_uploads with key *** at 
> org.apache.camel.RuntimeCamelException.wrapRuntimeCamelException(RuntimeCamelException.java:52)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:142)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregationRepositoryAdd(AggregateProcessor.java:644)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:598)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:406)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doInOptimisticLock(AggregateProcessor.java:372)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:362)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:320)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:702)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:616)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
>  at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:40)
>  at 
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.doRun(KafkaConsumer.java:346)
>  at 
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.run(KafkaConsumer.java:222)
>  at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  at java.base/java.lang.Thread.run(Thread.java:834) Caused by: 
> java.lang.RuntimeException: Error adding to repository lb_data_uploads with 
> key *** at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:176)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:149)
>  at 
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:149)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:137)
>  ... 21 common frames omitted Caused by: java.lang.NullPointerException: null 
> at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:167)
>  ... 25 common frames omitted{noformat}
>  
> The problematic code seems to be at *JdbcAggregationRepository.java* line 167:
> {noformat}
> private static final String VERSION_PROPERTY = "CamelOptimisticLockVersion";
> 
> long version = exchange.getProperty(VERSION_PROPERTY, Long.class);
> {noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CAMEL-15723) NPE when using PostgresAggregationRepository

[Benjamin BONNET (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17390515#comment-17390515
 ] 

Benjamin BONNET commented on CAMEL-15723:
-

Hi,

we are getting the same issue on a 3.7.5 release. 

java.lang.NullPointerExceptionjava.lang.NullPointerException at 
org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:171)

Incriminated line (171) contains same code as the one reported by 
[~corina.roman] 
|long version = exchange.getProperty(VERSION_PROPERTY, Long.class);|

Could you please reopen that issue ?

Regards

> NPE when using PostgresAggregationRepository
> 
>
> Key: CAMEL-15723
> URL: https://issues.apache.org/jira/browse/CAMEL-15723
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 3.4.2
> Environment: * Apache Camel 3.4.2
>  * Spring Boot 2.3.4.RELEASE
>  * Postgres database as an aggregate repository
>Reporter: Corina Roman
>Priority: Major
> Fix For: 3.x
>
>
> Hi,
> we are getting production errors (NPE) when using a Postgres aggregate 
> repository and Camel code attempts to write to that table (under concurrent 
> use):
> {noformat}
> org.apache.camel.RuntimeCamelException: java.lang.RuntimeException: Error 
> adding to repository lb_data_uploads with key *** at 
> org.apache.camel.RuntimeCamelException.wrapRuntimeCamelException(RuntimeCamelException.java:52)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:142)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregationRepositoryAdd(AggregateProcessor.java:644)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doAggregation(AggregateProcessor.java:598)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:406)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doInOptimisticLock(AggregateProcessor.java:372)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.doProcess(AggregateProcessor.java:362)
>  at 
> org.apache.camel.processor.aggregate.AggregateProcessor.process(AggregateProcessor.java:320)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:702)
>  at 
> org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:616)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:148)
>  at 
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
>  at org.apache.camel.processor.Pipeline.process(Pipeline.java:147) at 
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
>  at 
> org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
>  at 
> org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:40)
>  at 
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.doRun(KafkaConsumer.java:346)
>  at 
> org.apache.camel.component.kafka.KafkaConsumer$KafkaFetchRecords.run(KafkaConsumer.java:222)
>  at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  at java.base/java.lang.Thread.run(Thread.java:834) Caused by: 
> java.lang.RuntimeException: Error adding to repository lb_data_uploads with 
> key *** at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:176)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:149)
>  at 
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:149)
>  at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository.add(JdbcAggregationRepository.java:137)
>  ... 21 common frames omitted Caused by: java.lang.NullPointerException: null 
> at 
> org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository$1.doInTransaction(JdbcAggregationRepository.java:167)
>  ... 25 common frames omitted{noformat}
>  
> The problematic code seems to be at *JdbcAggregationRepository.java* line 167:
> {noformat}
> private static final String VERSION_PROPERTY = 

[jira] [Closed] (CAMEL-7701) Chaining cxfrs endpoints

[Benjamin BONNET (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET closed CAMEL-7701.
--

 Chaining cxfrs endpoints
 

 Key: CAMEL-7701
 URL: https://issues.apache.org/jira/browse/CAMEL-7701
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Affects Versions: 2.13.2, Future
 Environment: JDK7 / Windows7
 OpenJDK /Ubuntu Precise
Reporter: Benjamin BONNET
Assignee: Willem Jiang
 Fix For: 2.12.5, 2.13.3, 2.14.0


 Hi,
 chaining 2 cxfrs endpoints in a route reveals 2 problems :
 - proxy-client method choice in producer (CxfRsProducer.findRightMethod) is 
 way too restrictive : the choice is based on the name and the exact type of 
 the parameters. As a consequence, if parameters  type transmitted are 
 compatible (i.e. extend the signature parameter types) with the method 
 signature but are not the very ones of the signature, the operation will not 
 be found.
 That problem occurs when you chain 2 cxfrs endpoints having an InputStream 
 parameter since cxf uses DelegatingInputStream to handle received 
 InputStreams.
 That problem may also occur for any .to() cxfrs endpoint if the message 
 body uses subtypes of the parameters.
 - transmitting Content-Type header from camel to CXFRS request in 
 DefaultCxfRsBinding may cause trouble for multipart messages : actually, if 
 Content-Type contains a boundary defintion (which is the case when you chain 
 cxfrs endpoints), that definition will be included into the Content-Type 
 transmitted (in addition with the one generated during binding). That throws 
 an exception since the old boundary is not used in the transmitted message. 
 NB : header propagation was not enforced in 2.13.2 but it is enforced in head.
 I developped a JUnit test that shows such failures in the case of a cxfrs 
 endpoint chaining, and some code that prevents them. I am going to submit 
 them on github.
 Regards



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CAMEL-7883) XSD decoding bad guess in Validator

[Benjamin BONNET (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET closed CAMEL-7883.
--

Thank you Willem

 XSD decoding bad guess in Validator
 ---

 Key: CAMEL-7883
 URL: https://issues.apache.org/jira/browse/CAMEL-7883
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2, 2.14.0
Reporter: Benjamin BONNET
Assignee: Willem Jiang
 Fix For: 2.13.3, 2.14.1, 2.15.0


 Validator component does not take imported XSD encoding into account when 
 validating XML. That may lead to validation errors if an imported XSD is 
 ISO-8859-1 encoded and containing non ASCII caracters, even though that XSD 
 declares its encoding correctly in its XML prolog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7766) Exception in split does not trigger onException in main route

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153886#comment-14153886
 ] 

Benjamin BONNET commented on CAMEL-7766:


Hi,
after cleaning-up my repo, I created pull request 290 : 
https://github.com/apache/camel/pull/290
Regards

 Exception in split does not trigger onException in main route
 -

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split does not trigger onException applying 
 to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-7883) XSD decoding bad guess in Validator

[Benjamin BONNET (JIRA)]

Benjamin BONNET created CAMEL-7883:
--

 Summary: XSD decoding bad guess in Validator
 Key: CAMEL-7883
 URL: https://issues.apache.org/jira/browse/CAMEL-7883
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2, 2.15.0
Reporter: Benjamin BONNET


Validator component does not take imported XSD encoding into account when 
validating XML. That may lead to validation errors if an imported XSD is 
ISO-8859-1 encoded and containing non ASCII caracters, even though that XSD 
declares its encoding correctly in its XML prolog.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7883) XSD decoding bad guess in Validator

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153949#comment-14153949
 ] 

Benjamin BONNET commented on CAMEL-7883:


Hi,
when an imported XSD is decoded, Camel uses a converter defined in context. 
That converter involves a reader that will not take into account the XSD XML 
prolog. If that reader does not use the same encoding as one of the imported 
XSD, you may get into trouble while validating XML files.
Instead of providing the content of XSD as char stream, I think it is more 
appropriate to provide it as a binary stream and let Sax make a good guess 
about the XSD encoding.
I made a pull request on github with a unit test and a fix : see 
https://github.com/apache/camel/pull/291
Regards

 XSD decoding bad guess in Validator
 ---

 Key: CAMEL-7883
 URL: https://issues.apache.org/jira/browse/CAMEL-7883
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2, 2.15.0
Reporter: Benjamin BONNET

 Validator component does not take imported XSD encoding into account when 
 validating XML. That may lead to validation errors if an imported XSD is 
 ISO-8859-1 encoded and containing non ASCII caracters, even though that XSD 
 declares its encoding correctly in its XML prolog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7766) Exception in split does not trigger onException in main route

[Benjamin BONNET (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET updated CAMEL-7766:
---
Summary: Exception in split does not trigger onException in main route  
(was: Exception in split is not propagated)

 Exception in split does not trigger onException in main route
 -

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7766) Exception in split does not trigger onException in main route

[Benjamin BONNET (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET updated CAMEL-7766:
---
Description: 
Exception thrown in a sequential split does not trigger onException applying to 
main route.
That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)

  was:
Exception thrown in a sequential split is not propagated to main route.
That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)


 Exception in split does not trigger onException in main route
 -

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split does not trigger onException applying 
 to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7766) Exception in split does not trigger onException in main route

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146090#comment-14146090
 ] 

Benjamin BONNET commented on CAMEL-7766:


Hi,
I changed this issue title since exception thrown in the split does propagate 
to errorHandler but does not trigger onException that applies to main route.
Regards.

 Exception in split does not trigger onException in main route
 -

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split does not trigger onException applying 
 to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14125503#comment-14125503
 ] 

Benjamin BONNET commented on CAMEL-7766:


Hi,
were you able to give that unit test a shot ?
Regards

 Exception in split is not propagated
 

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin BONNET reopened CAMEL-7766:


Hi, 
using shareUnitOfWork does not seem to do the trick either : in my unit test, 
adding shareUnitOfWork, the exception thrown by the split is not caught neither 
by the split onException, nor by the main route onException.
Regards

 Exception in split is not propagated
 

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14116886#comment-14116886
 ] 

Benjamin BONNET edited comment on CAMEL-7766 at 8/31/14 8:58 PM:
-

Hi, 
using shareUnitOfWork does not seem to do the trick either : in my unit test, 
adding shareUnitOfWork, the exception thrown by the split is not caught neither 
by the split onException, nor by the main route onException.
Regards

PS : I added two tests to my unit test, in ordre to combine stopOnException and 
shareUnitOfWork options


was (Author: bbonnet):
Hi, 
using shareUnitOfWork does not seem to do the trick either : in my unit test, 
adding shareUnitOfWork, the exception thrown by the split is not caught neither 
by the split onException, nor by the main route onException.
Regards

 Exception in split is not propagated
 

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14116566#comment-14116566
 ] 

Benjamin BONNET commented on CAMEL-7766:


Hi,
I created a new pull request with appropriate commit range.
Regards

 Exception in split is not propagated
 

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

Benjamin BONNET created CAMEL-7766:
--

 Summary: Exception in split is not propagated
 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET


Exception thrown in a sequential split is not propagated to main route.
That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14115844#comment-14115844
 ] 

Benjamin BONNET commented on CAMEL-7766:


See 
https://github.com/bonnetb/camel/commit/d40c998509d99ddd45c49e95e31a96d43c827038
 for a unit test + a quick fix

 Exception in split is not propagated
 

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CAMEL-7766) Exception in split is not propagated

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14115844#comment-14115844
 ] 

Benjamin BONNET edited comment on CAMEL-7766 at 8/29/14 9:20 PM:
-

See 
https://github.com/bonnetb/camel/commit/d40c998509d99ddd45c49e95e31a96d43c827038
 for a unit test + a quick fix

PS : I closed my pull request since its commit range was to wide.


was (Author: bbonnet):
See 
https://github.com/bonnetb/camel/commit/d40c998509d99ddd45c49e95e31a96d43c827038
 for a unit test + a quick fix

 Exception in split is not propagated
 

 Key: CAMEL-7766
 URL: https://issues.apache.org/jira/browse/CAMEL-7766
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.13.2
 Environment: JDK7 / W7
Reporter: Benjamin BONNET

 Exception thrown in a sequential split is not propagated to main route.
 That bug may be a regression linked to commit#78c7350 (CAMEL-5681 fix)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CAMEL-7701) Chaining cxfrs endpoints

[Benjamin BONNET (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102844#comment-14102844
 ] 

Benjamin BONNET commented on CAMEL-7701:


Thank you, Willem.

 Chaining cxfrs endpoints
 

 Key: CAMEL-7701
 URL: https://issues.apache.org/jira/browse/CAMEL-7701
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Affects Versions: 2.13.2, Future
 Environment: JDK7 / Windows7
 OpenJDK /Ubuntu Precise
Reporter: Benjamin BONNET
Assignee: Willem Jiang
 Fix For: 2.12.5, 2.13.3, 2.14.0


 Hi,
 chaining 2 cxfrs endpoints in a route reveals 2 problems :
 - proxy-client method choice in producer (CxfRsProducer.findRightMethod) is 
 way too restrictive : the choice is based on the name and the exact type of 
 the parameters. As a consequence, if parameters  type transmitted are 
 compatible (i.e. extend the signature parameter types) with the method 
 signature but are not the very ones of the signature, the operation will not 
 be found.
 That problem occurs when you chain 2 cxfrs endpoints having an InputStream 
 parameter since cxf uses DelegatingInputStream to handle received 
 InputStreams.
 That problem may also occur for any .to() cxfrs endpoint if the message 
 body uses subtypes of the parameters.
 - transmitting Content-Type header from camel to CXFRS request in 
 DefaultCxfRsBinding may cause trouble for multipart messages : actually, if 
 Content-Type contains a boundary defintion (which is the case when you chain 
 cxfrs endpoints), that definition will be included into the Content-Type 
 transmitted (in addition with the one generated during binding). That throws 
 an exception since the old boundary is not used in the transmitted message. 
 NB : header propagation was not enforced in 2.13.2 but it is enforced in head.
 I developped a JUnit test that shows such failures in the case of a cxfrs 
 endpoint chaining, and some code that prevents them. I am going to submit 
 them on github.
 Regards



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CAMEL-7701) Chaining cxfrs endpoints

[Benjamin BONNET (JIRA)]

Benjamin BONNET created CAMEL-7701:
--

 Summary: Chaining cxfrs endpoints
 Key: CAMEL-7701
 URL: https://issues.apache.org/jira/browse/CAMEL-7701
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Affects Versions: 2.13.2, Future
 Environment: JDK7 / Windows7
OpenJDK /Ubuntu Precise
Reporter: Benjamin BONNET


Hi,
chaining 2 cxfrs endpoints in a route reveals 2 problems :
- proxy-client method choice in producer (CxfRsProducer.findRightMethod) is way 
too restrictive : the choice is based on the name and the exact type of the 
parameters. As a consequence, if parameters  type transmitted are compatible 
(i.e. extend the signature parameter types) with the method signature but are 
not the very ones of the signature, the operation will not be found.
That problem occurs when you chain 2 cxfrs endpoints having an InputStream 
parameter since cxf uses DelegatingInputStream to handle received InputStreams.
That problem may also occur for any .to() cxfrs endpoint if the message body 
uses subtypes of the parameters.
- transmitting Content-Type header from camel to CXFRS request in 
DefaultCxfRsBinding may cause trouble for multipart messages : actually, if 
Content-Type contains a boundary defintion (which is the case when you chain 
cxfrs endpoints), that definition will be included into the Content-Type 
transmitted (in addition with the one generated during binding). That throws an 
exception since the old boundary is not used in the transmitted message. NB : 
header propagation was not enforced in 2.13.2 but it is enforced in head.

I developped a JUnit test that shows such failures in the case of a cxfrs 
endpoint chaining, and some code that prevents them. I am going to submit them 
on github.

Regards



--
This message was sent by Atlassian JIRA
(v6.2#6252)