[jira] [Commented] (CAMEL-9364) Add ability to receive onOpen/onClose/onError websocket events through camel rout.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9364:
---

GitHub user pkletsko opened a pull request:

https://github.com/apache/camel/pull/697

[CAMEL-9364] Add ability to receive onOpen/onClose/onError websocket …

…events through camel rout.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pkletsko/camel CAMEL-9364

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/697.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #697


commit 011482b4f8c22de5713dc85c8b7ae9f9b613cca2
Author: Pavlo Kletsko 
Date:   2015-11-26T09:30:04Z

[CAMEL-9364] Add ability to receive onOpen/onClose/onError websocket events 
through camel rout.




> Add ability to receive onOpen/onClose/onError websocket events through camel 
> rout.
> --
>
> Key: CAMEL-9364
> URL: https://issues.apache.org/jira/browse/CAMEL-9364
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-atmosphere-websocket
>Reporter: Pavlo Kletsko
>  Labels: patch
> Fix For: 2.17.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> There is a case when I need to maintain my own map (websocket session key, 
> user object). Consequently I need to receive events from 
> onOpen/onClose/onError methods of websocket protocol and add/remove item from 
> my map. 
> To achieve this :
> 1) I will add special servlet parameter, let's call it "events" with value 
> "true". Which will enable this feature. By default it will be "false" (no 
> parameter needed) and current functionality will not be influenced any how.
> 
>   CamelWsServlet
>   
> org.apache.camel.component.atmosphere.websocket.CamelWebSocketServlet
>   
>   events
>   true
>   
>   2
>   
> 2) I will change WebsocketHandler sending exchange message with header key 
> such as "websocket.eventType" and possible values :
> ONOPEN_EVENT_TYPE = 1;
> ONCLOSE_EVENT_TYPE = 0;
> ONERROR_EVENT_TYPE = -1;
> to camel rout each time when we trigger onOpen/onClose/onError methods. In 
> addition to this header parameter session key will be send as well. 
> 3) Rout on client side will filter messages by header to distinguish events 
> and their purposes.  



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

[jira] [Commented] (CAMEL-8302) Rabbitmq shouldn't require/bind queue if not specified

[Hendy Irawan (JIRA)]

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

Hendy Irawan commented on CAMEL-8302:
-

Thank you [~davewilliams] [~cibsen] ! But what's the difference betwen 
{{declare}} and {{skipQueueDeclare}}?

> Rabbitmq shouldn't require/bind queue if not specified 
> ---
>
> Key: CAMEL-8302
> URL: https://issues.apache.org/jira/browse/CAMEL-8302
> Project: Camel
>  Issue Type: Bug
>  Components: camel-rabbitmq
>Affects Versions: 2.14.1
>Reporter: Sajjad Akhter
>Assignee: Claus Ibsen
> Fix For: 2.16.1, 2.17.0
>
>
> Current implementation is declaring both exchange and queue on any init 
> (producer or consumer). In case of producer one don't need queue and may not 
> know who going to be client. 
> We can add flag skipQueueDeclare  so that it won't genrate uuid queue. 
> i can provide PR if it helps. 



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

[jira] [Resolved] (CAMEL-9364) Add ability to receive onOpen/onClose/onError websocket events through camel rout.

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9364.

Resolution: Fixed
  Assignee: Claus Ibsen

Thanks for the PR

> Add ability to receive onOpen/onClose/onError websocket events through camel 
> rout.
> --
>
> Key: CAMEL-9364
> URL: https://issues.apache.org/jira/browse/CAMEL-9364
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-atmosphere-websocket
>Reporter: Pavlo Kletsko
>Assignee: Claus Ibsen
>  Labels: patch
> Fix For: 2.17.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> There is a case when I need to maintain my own map (websocket session key, 
> user object). Consequently I need to receive events from 
> onOpen/onClose/onError methods of websocket protocol and add/remove item from 
> my map. 
> To achieve this :
> 1) I will add special servlet parameter, let's call it "events" with value 
> "true". Which will enable this feature. By default it will be "false" (no 
> parameter needed) and current functionality will not be influenced any how.
> 
>   CamelWsServlet
>   
> org.apache.camel.component.atmosphere.websocket.CamelWebSocketServlet
>   
>   events
>   true
>   
>   2
>   
> 2) I will change WebsocketHandler sending exchange message with header key 
> such as "websocket.eventType" and possible values :
> ONOPEN_EVENT_TYPE = 1;
> ONCLOSE_EVENT_TYPE = 0;
> ONERROR_EVENT_TYPE = -1;
> to camel rout each time when we trigger onOpen/onClose/onError methods. In 
> addition to this header parameter session key will be send as well. 
> 3) Rout on client side will filter messages by header to distinguish events 
> and their purposes.  



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

[jira] [Commented] (CAMEL-9364) Add ability to receive onOpen/onClose/onError websocket events through camel rout.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9364:
---

Github user pkletsko closed the pull request at:

https://github.com/apache/camel/pull/697


> Add ability to receive onOpen/onClose/onError websocket events through camel 
> rout.
> --
>
> Key: CAMEL-9364
> URL: https://issues.apache.org/jira/browse/CAMEL-9364
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-atmosphere-websocket
>Reporter: Pavlo Kletsko
>Assignee: Claus Ibsen
>  Labels: patch
> Fix For: 2.17.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> There is a case when I need to maintain my own map (websocket session key, 
> user object). Consequently I need to receive events from 
> onOpen/onClose/onError methods of websocket protocol and add/remove item from 
> my map. 
> To achieve this :
> 1) I will add special servlet parameter, let's call it "events" with value 
> "true". Which will enable this feature. By default it will be "false" (no 
> parameter needed) and current functionality will not be influenced any how.
> 
>   CamelWsServlet
>   
> org.apache.camel.component.atmosphere.websocket.CamelWebSocketServlet
>   
>   events
>   true
>   
>   2
>   
> 2) I will change WebsocketHandler sending exchange message with header key 
> such as "websocket.eventType" and possible values :
> ONOPEN_EVENT_TYPE = 1;
> ONCLOSE_EVENT_TYPE = 0;
> ONERROR_EVENT_TYPE = -1;
> to camel rout each time when we trigger onOpen/onClose/onError methods. In 
> addition to this header parameter session key will be send as well. 
> 3) Rout on client side will filter messages by header to distinguish events 
> and their purposes.  



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

[jira] [Commented] (CAMEL-9364) Add ability to receive onOpen/onClose/onError websocket events through camel rout.

[Pavlo Kletsko (JIRA)]

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

Pavlo Kletsko commented on CAMEL-9364:
--

Super, thanks. 

> Add ability to receive onOpen/onClose/onError websocket events through camel 
> rout.
> --
>
> Key: CAMEL-9364
> URL: https://issues.apache.org/jira/browse/CAMEL-9364
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-atmosphere-websocket
>Reporter: Pavlo Kletsko
>Assignee: Claus Ibsen
>  Labels: patch
> Fix For: 2.17.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> There is a case when I need to maintain my own map (websocket session key, 
> user object). Consequently I need to receive events from 
> onOpen/onClose/onError methods of websocket protocol and add/remove item from 
> my map. 
> To achieve this :
> 1) I will add special servlet parameter, let's call it "events" with value 
> "true". Which will enable this feature. By default it will be "false" (no 
> parameter needed) and current functionality will not be influenced any how.
> 
>   CamelWsServlet
>   
> org.apache.camel.component.atmosphere.websocket.CamelWebSocketServlet
>   
>   events
>   true
>   
>   2
>   
> 2) I will change WebsocketHandler sending exchange message with header key 
> such as "websocket.eventType" and possible values :
> ONOPEN_EVENT_TYPE = 1;
> ONCLOSE_EVENT_TYPE = 0;
> ONERROR_EVENT_TYPE = -1;
> to camel rout each time when we trigger onOpen/onClose/onError methods. In 
> addition to this header parameter session key will be send as well. 
> 3) Rout on client side will filter messages by header to distinguish events 
> and their purposes.  



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

[jira] [Updated] (CAMEL-9202) Flatpack: Body reader never closed

[MykhailoVlakh (JIRA)]

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

MykhailoVlakh updated CAMEL-9202:
-
Attachment: patchfile2.diff

Added a new patch with a fix for the issue in the delimited content parser 
creation code which does not allow to use isAllowShortLines and 
isIgnoreExtraColumns if PZMAP is not used.

> Flatpack: Body reader never closed 
> ---
>
> Key: CAMEL-9202
> URL: https://issues.apache.org/jira/browse/CAMEL-9202
> Project: Camel
>  Issue Type: Bug
>  Components: camel-flatpack
>Affects Versions: 2.14.3
>Reporter: MykhailoVlakh
>Assignee: Claus Ibsen
> Fix For: 2.16.2, 2.15.5, 2.17.0
>
> Attachments: patchfile.diff, patchfile2.diff
>
>
> Hello Camel team,
> First of all I want to thank you for all great work you do to provide such a 
> powerful tool as Camel. I really enjoy using it in my work. 
> Currently I am working on an application that requires delimited and fixed 
> width parsing tools and I decided to use Camel Flatpack because we already 
> use some other Camel stuff. We use Camel 2.14.3 which is not the latest one 
> but forks fine. During my work with Flatpack consumer I found several issues 
> and some room for improvements and I decided to share my thoughts/findings 
> with you. Our team have plans to migrate to the latest version of Camel in 
> near future and we all will be happy if the new version includes 
> fixes/improvements that I am goint to suggest.
> The main issue that I found is that flatpack endpoint does not close body 
> reader if an exception is thrown during parser creation step. As a result the 
> related resource remains opened forever. For example in my cases when PZMAP 
> files was missing my data file (csv file) was locked and my file consumer 
> ended in endless loop in which it was trying to move a file to .error folder 
> but was not able to do this because the file was opened for read.
> Another problem that I noticed is that I cannot use allowShortLines and 
> ignoreExtraColumns attributes if my parser uses inline headers from files. 
> Flatpack simply ignores them in this case.
> Finally I think that there is some  room for improvements:
> * It would be nice to have a possibility to provide PZMAP as a bean via JNDI 
> context instead of having to generate a file. This feature will be very 
> useful and content parsing should work faster because the XML will be read 
> from memory instead of reading it from a file each time you parse some 
> content;
> * It would be nice to have a possibility to provide content format as an URI 
> attribute instead of using these ugly URI prefixes that we should use right 
> now. With such possibility in plase URI will look the same all the time and 
> developers won't need to reformat URI differently for different content types.
> I attached a patch file with code fragments and comments to them that 
> illustrate my findings/thoughts. Unformtunatelly I don't have enough time to 
> provide real fixes and unit tests so please excuse me for this. 
> Please let me know if something is unclear or require more details.
> Looking forward for your feedback,
> Mykhailo



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

[jira] [Commented] (CAMEL-9202) Flatpack: Body reader never closed

[MykhailoVlakh (JIRA)]

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

MykhailoVlakh commented on CAMEL-9202:
--

Sorry for a delay. Attached a new diff file with the necessary changes.

> Flatpack: Body reader never closed 
> ---
>
> Key: CAMEL-9202
> URL: https://issues.apache.org/jira/browse/CAMEL-9202
> Project: Camel
>  Issue Type: Bug
>  Components: camel-flatpack
>Affects Versions: 2.14.3
>Reporter: MykhailoVlakh
>Assignee: Claus Ibsen
> Fix For: 2.16.2, 2.15.5, 2.17.0
>
> Attachments: patchfile.diff, patchfile2.diff
>
>
> Hello Camel team,
> First of all I want to thank you for all great work you do to provide such a 
> powerful tool as Camel. I really enjoy using it in my work. 
> Currently I am working on an application that requires delimited and fixed 
> width parsing tools and I decided to use Camel Flatpack because we already 
> use some other Camel stuff. We use Camel 2.14.3 which is not the latest one 
> but forks fine. During my work with Flatpack consumer I found several issues 
> and some room for improvements and I decided to share my thoughts/findings 
> with you. Our team have plans to migrate to the latest version of Camel in 
> near future and we all will be happy if the new version includes 
> fixes/improvements that I am goint to suggest.
> The main issue that I found is that flatpack endpoint does not close body 
> reader if an exception is thrown during parser creation step. As a result the 
> related resource remains opened forever. For example in my cases when PZMAP 
> files was missing my data file (csv file) was locked and my file consumer 
> ended in endless loop in which it was trying to move a file to .error folder 
> but was not able to do this because the file was opened for read.
> Another problem that I noticed is that I cannot use allowShortLines and 
> ignoreExtraColumns attributes if my parser uses inline headers from files. 
> Flatpack simply ignores them in this case.
> Finally I think that there is some  room for improvements:
> * It would be nice to have a possibility to provide PZMAP as a bean via JNDI 
> context instead of having to generate a file. This feature will be very 
> useful and content parsing should work faster because the XML will be read 
> from memory instead of reading it from a file each time you parse some 
> content;
> * It would be nice to have a possibility to provide content format as an URI 
> attribute instead of using these ugly URI prefixes that we should use right 
> now. With such possibility in plase URI will look the same all the time and 
> developers won't need to reformat URI differently for different content types.
> I attached a patch file with code fragments and comments to them that 
> illustrate my findings/thoughts. Unformtunatelly I don't have enough time to 
> provide real fixes and unit tests so please excuse me for this. 
> Please let me know if something is unclear or require more details.
> Looking forward for your feedback,
> Mykhailo



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

[jira] [Created] (CAMEL-9366) CXFRS "skipFaultLogging" attribute doesn't work in Spring

[Gert Vanthienen (JIRA)]

Gert Vanthienen created CAMEL-9366:
--

 Summary: CXFRS "skipFaultLogging" attribute doesn't work in Spring
 Key: CAMEL-9366
 URL: https://issues.apache.org/jira/browse/CAMEL-9366
 Project: Camel
  Issue Type: Bug
  Components: camel-cxfrs
Affects Versions: 2.16.1
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen
 Fix For: 2.16.2, 2.17.0


When defining a camel-cxf cxf:rsClient bean with skipFaultLogging enabled, like 
this

{code}
http://localhost:9081/CxfRsService/rest;
serviceClass="org.apache.camel.component.cxf.jaxrs.testbean.CustomerService"
skipFaultLogging="true" />
{code}

... the exception will still be logged. If you add the flag to the endpoint URI 
instead, {{skipFaultLogging}} works as expected.



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

[jira] [Updated] (CAMEL-9366) CXFRS "skipFaultLogging" attribute doesn't work in Spring

[Gert Vanthienen (JIRA)]

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

Gert Vanthienen updated CAMEL-9366:
---
Component/s: (was: camel-cxfrs)
 camel-cxf

> CXFRS "skipFaultLogging" attribute doesn't work in Spring
> -
>
> Key: CAMEL-9366
> URL: https://issues.apache.org/jira/browse/CAMEL-9366
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.1
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: 2.16.2, 2.17.0
>
>
> When defining a camel-cxf cxf:rsClient bean with skipFaultLogging enabled, 
> like this
> {code}
>  address="http://localhost:9081/CxfRsService/rest;
> 
> serviceClass="org.apache.camel.component.cxf.jaxrs.testbean.CustomerService"
> skipFaultLogging="true" />
> {code}
> ... the exception will still be logged. If you add the flag to the endpoint 
> URI instead, {{skipFaultLogging}} works as expected.



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

[jira] [Commented] (CAMEL-9366) CXFRS "skipFaultLogging" attribute doesn't work in Spring

[Gert Vanthienen (JIRA)]

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

Gert Vanthienen commented on CAMEL-9366:


When going through the Spring factory bean, the code was adding the {{beanId}} 
to the endpoint properties in one place and the {{FaultListener}} in another 
place.  In the normal {{CxfEndpoint}}, we were merging these properties into a 
single properties map, but that bit of code was missing from the 
{{SpringJAXRSClientFactoryBean}}

Fixed for {{master}} in 
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commitdiff;h=cfa51caf21c7022a62f1bff0142eada38fa3dbdc


> CXFRS "skipFaultLogging" attribute doesn't work in Spring
> -
>
> Key: CAMEL-9366
> URL: https://issues.apache.org/jira/browse/CAMEL-9366
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.1
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: 2.16.2, 2.17.0
>
>
> When defining a camel-cxf cxf:rsClient bean with skipFaultLogging enabled, 
> like this
> {code}
>  address="http://localhost:9081/CxfRsService/rest;
> 
> serviceClass="org.apache.camel.component.cxf.jaxrs.testbean.CustomerService"
> skipFaultLogging="true" />
> {code}
> ... the exception will still be logged. If you add the flag to the endpoint 
> URI instead, {{skipFaultLogging}} works as expected.



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

[jira] [Commented] (CAMEL-9202) Flatpack: Body reader never closed

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9202:


Thanks for the 2nd patch.

> Flatpack: Body reader never closed 
> ---
>
> Key: CAMEL-9202
> URL: https://issues.apache.org/jira/browse/CAMEL-9202
> Project: Camel
>  Issue Type: Bug
>  Components: camel-flatpack
>Affects Versions: 2.14.3
>Reporter: MykhailoVlakh
>Assignee: Claus Ibsen
> Fix For: 2.16.2, 2.15.5, 2.17.0
>
> Attachments: patchfile.diff, patchfile2.diff
>
>
> Hello Camel team,
> First of all I want to thank you for all great work you do to provide such a 
> powerful tool as Camel. I really enjoy using it in my work. 
> Currently I am working on an application that requires delimited and fixed 
> width parsing tools and I decided to use Camel Flatpack because we already 
> use some other Camel stuff. We use Camel 2.14.3 which is not the latest one 
> but forks fine. During my work with Flatpack consumer I found several issues 
> and some room for improvements and I decided to share my thoughts/findings 
> with you. Our team have plans to migrate to the latest version of Camel in 
> near future and we all will be happy if the new version includes 
> fixes/improvements that I am goint to suggest.
> The main issue that I found is that flatpack endpoint does not close body 
> reader if an exception is thrown during parser creation step. As a result the 
> related resource remains opened forever. For example in my cases when PZMAP 
> files was missing my data file (csv file) was locked and my file consumer 
> ended in endless loop in which it was trying to move a file to .error folder 
> but was not able to do this because the file was opened for read.
> Another problem that I noticed is that I cannot use allowShortLines and 
> ignoreExtraColumns attributes if my parser uses inline headers from files. 
> Flatpack simply ignores them in this case.
> Finally I think that there is some  room for improvements:
> * It would be nice to have a possibility to provide PZMAP as a bean via JNDI 
> context instead of having to generate a file. This feature will be very 
> useful and content parsing should work faster because the XML will be read 
> from memory instead of reading it from a file each time you parse some 
> content;
> * It would be nice to have a possibility to provide content format as an URI 
> attribute instead of using these ugly URI prefixes that we should use right 
> now. With such possibility in plase URI will look the same all the time and 
> developers won't need to reformat URI differently for different content types.
> I attached a patch file with code fragments and comments to them that 
> illustrate my findings/thoughts. Unformtunatelly I don't have enough time to 
> provide real fixes and unit tests so please excuse me for this. 
> Please let me know if something is unclear or require more details.
> Looking forward for your feedback,
> Mykhailo



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

[jira] [Resolved] (CAMEL-9366) CXFRS "skipFaultLogging" attribute doesn't work in Spring

[Gert Vanthienen (JIRA)]

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

Gert Vanthienen resolved CAMEL-9366.

   Resolution: Fixed
Fix Version/s: 2.15.5

Fixed in...
* 
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commitdiff;h=083b89bfadfb7c9436347d43199fc92516abaaa5
 for {{camel-2.16.x}}
* 
https://git-wip-us.apache.org/repos/asf?p=camel.git;a=commitdiff;h=5347e630a08cb71ee8ef329072641b7d8fc4895d
 for {{camel-2.15.x}}

> CXFRS "skipFaultLogging" attribute doesn't work in Spring
> -
>
> Key: CAMEL-9366
> URL: https://issues.apache.org/jira/browse/CAMEL-9366
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.1
>Reporter: Gert Vanthienen
>Assignee: Gert Vanthienen
> Fix For: 2.16.2, 2.15.5, 2.17.0
>
>
> When defining a camel-cxf cxf:rsClient bean with skipFaultLogging enabled, 
> like this
> {code}
>  address="http://localhost:9081/CxfRsService/rest;
> 
> serviceClass="org.apache.camel.component.cxf.jaxrs.testbean.CustomerService"
> skipFaultLogging="true" />
> {code}
> ... the exception will still be logged. If you add the flag to the endpoint 
> URI instead, {{skipFaultLogging}} works as expected.



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

[jira] [Commented] (CAMEL-9361) Upgrade Kafka to 0.9.0

[James Netherton (JIRA)]

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

James Netherton commented on CAMEL-9361:


After a couple of small tweaks, the existing codebase seems to work fine with 
the updated Kafka library (the old API will remain supported for some time).  

This gives us a lazy route for upgrading.

If we're wanting to support the newer Kafka producer / consumer APIs, then I'll 
leave that to someone who has a better understanding of Kafka. 

> Upgrade Kafka to 0.9.0
> --
>
> Key: CAMEL-9361
> URL: https://issues.apache.org/jira/browse/CAMEL-9361
> Project: Camel
>  Issue Type: Task
>  Components: camel-kafka
>Reporter: James Netherton
> Fix For: 2.17.0
>
>
> Kafka 0.9.0 is now available. It'd be nice if we could upgrade the camel 
> component to use this. 
> There are some fixes that make Kafka play better in modular runtime 
> environments that I'm interested in trying on WildFly.



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

[jira] [Commented] (CAMEL-9361) Upgrade Kafka to 0.9.0

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino commented on CAMEL-9361:
-

For the moment, I think we can just upgrade the version and leave the new Kafka 
Producer/Consumer APIs support for the future. 

> Upgrade Kafka to 0.9.0
> --
>
> Key: CAMEL-9361
> URL: https://issues.apache.org/jira/browse/CAMEL-9361
> Project: Camel
>  Issue Type: Task
>  Components: camel-kafka
>Reporter: James Netherton
> Fix For: 2.17.0
>
>
> Kafka 0.9.0 is now available. It'd be nice if we could upgrade the camel 
> component to use this. 
> There are some fixes that make Kafka play better in modular runtime 
> environments that I'm interested in trying on WildFly.



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

[jira] [Updated] (CAMEL-8271) camel-rabbitmq: Builtin exchanges should not require autoDelete & exchangeType properties

[Hendy Irawan (JIRA)]

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

Hendy Irawan updated CAMEL-8271:

Description: 
Currently all exchanges must set the {{autoDelete}} and {{exchangeType}} 
properties, and cannot be left empty, otherwise camel-rabbitmq will complain 
that these don't match.

The RabbitMQ builtin exchanges have predefined behavior and should be usable 
from {{camel-rabbitmq}} without setting these properties:

1. {{""}} / {{amq.direct}}
2. {{amq.fanout}}
3. {{amq.topic}}
4. {{amq.match}}, {{amq.headers}}

In addition, when consuming from these, {{durable}} & {{autoDelete}} should 
configure the queue that will be bound to these exchanges, not the current 
behavior of configuring these builtin exchanges.

For example, currently it's impossible to do:

{{rabbitmq://localhost/amq.topic?durable=false=true=lumen.speech.synthesis}}

Which is actually is a common scenario: declare a durable, auto-delete, 
autonamed queue that is bound to exchange {{amq.topic}} and routing key 
{{lumen.speech.synthesis}}. Instead, RabbitMQ fails with error.

Another request is to support {{exclusive=true}}, which is typically used for 
autogenerated queues.

Reference: https://www.rabbitmq.com/tutorials/amqp-concepts.html

Relates to CAMEL-8270

  was:
Currently all exchanges must set the {{autoDelete}} and {{exchangeType}} 
properties, and cannot be left empty, otherwise camel-rabbitmq will complain 
that these don't match.

The RabbitMQ builtin exchanges have predefined behavior and should be usable 
from {{camel-rabbitmq}} without setting these properties:

1. "" / amq.direct
2. amq.fanout
3. amq.topic
4. amq.match, amq.headers

Reference: https://www.rabbitmq.com/tutorials/amqp-concepts.html

Relates to CAMEL-8270


> camel-rabbitmq: Builtin exchanges should not require autoDelete & 
> exchangeType properties
> -
>
> Key: CAMEL-8271
> URL: https://issues.apache.org/jira/browse/CAMEL-8271
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 2.14.1
>Reporter: Hendy Irawan
>Priority: Trivial
>
> Currently all exchanges must set the {{autoDelete}} and {{exchangeType}} 
> properties, and cannot be left empty, otherwise camel-rabbitmq will complain 
> that these don't match.
> The RabbitMQ builtin exchanges have predefined behavior and should be usable 
> from {{camel-rabbitmq}} without setting these properties:
> 1. {{""}} / {{amq.direct}}
> 2. {{amq.fanout}}
> 3. {{amq.topic}}
> 4. {{amq.match}}, {{amq.headers}}
> In addition, when consuming from these, {{durable}} & {{autoDelete}} should 
> configure the queue that will be bound to these exchanges, not the current 
> behavior of configuring these builtin exchanges.
> For example, currently it's impossible to do:
> {{rabbitmq://localhost/amq.topic?durable=false=true=lumen.speech.synthesis}}
> Which is actually is a common scenario: declare a durable, auto-delete, 
> autonamed queue that is bound to exchange {{amq.topic}} and routing key 
> {{lumen.speech.synthesis}}. Instead, RabbitMQ fails with error.
> Another request is to support {{exclusive=true}}, which is typically used for 
> autogenerated queues.
> Reference: https://www.rabbitmq.com/tutorials/amqp-concepts.html
> Relates to CAMEL-8270



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

[jira] [Updated] (CAMEL-8271) camel-rabbitmq: Builtin exchanges should support autoDelete & exchangeType as properties for queue declare

[Hendy Irawan (JIRA)]

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

Hendy Irawan updated CAMEL-8271:

Summary: camel-rabbitmq: Builtin exchanges should support autoDelete & 
exchangeType as properties for queue declare  (was: camel-rabbitmq: Builtin 
exchanges should not require autoDelete & exchangeType properties)

> camel-rabbitmq: Builtin exchanges should support autoDelete & exchangeType as 
> properties for queue declare
> --
>
> Key: CAMEL-8271
> URL: https://issues.apache.org/jira/browse/CAMEL-8271
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 2.14.1
>Reporter: Hendy Irawan
>Priority: Trivial
>
> Currently all exchanges must set the {{autoDelete}} and {{exchangeType}} 
> properties, and cannot be left empty, otherwise camel-rabbitmq will complain 
> that these don't match.
> The RabbitMQ builtin exchanges have predefined behavior and should be usable 
> from {{camel-rabbitmq}} without setting these properties:
> 1. {{""}} / {{amq.direct}}
> 2. {{amq.fanout}}
> 3. {{amq.topic}}
> 4. {{amq.match}}, {{amq.headers}}
> In addition, when consuming from these, {{durable}} & {{autoDelete}} should 
> configure the queue that will be bound to these exchanges, not the current 
> behavior of configuring these builtin exchanges.
> For example, currently it's impossible to do:
> {{rabbitmq://localhost/amq.topic?durable=false=true=lumen.speech.synthesis}}
> Which is actually is a common scenario: declare a durable, auto-delete, 
> autonamed queue that is bound to exchange {{amq.topic}} and routing key 
> {{lumen.speech.synthesis}}. Instead, RabbitMQ fails with error.
> Another request is to support {{exclusive=true}}, which is typically used for 
> autogenerated queues.
> Reference: https://www.rabbitmq.com/tutorials/amqp-concepts.html
> Relates to CAMEL-8270



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

[jira] [Commented] (CAMEL-9340) FileIdempotentRepository fails to create fileStore when no path is specified

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9340:
---

GitHub user snurmine opened a pull request:

https://github.com/apache/camel/pull/698

CAMEL-9340: Using user.dir as default dir for fileStore file when fil…

CAMEL-9340: Using user.dir as default dir for fileStore file when fileStore 
when file has no parent dir.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/snurmine/camel CAMEL-9340

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/698.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #698






> FileIdempotentRepository fails to create fileStore when no path is specified
> 
>
> Key: CAMEL-9340
> URL: https://issues.apache.org/jira/browse/CAMEL-9340
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.0
>Reporter: Ken Geis
>Priority: Trivial
> Fix For: 2.16.2, 2.17.0
>
>
> I create a FileIdempotentRepository like this:
> {code}
> .idempotentConsumer(fileIdempotentRepository(new File('ids'))) {
> it.in.body.id
> }
> {code}
> I get an error, and I traced it to:
> {noformat}
> Caused by: java.lang.NullPointerException: null
>   at 
> org.apache.camel.processor.idempotent.mpotentRepository.loadStore(FileIdempotentRepository.java:293)
>  ~[camel-core-2.16.0.jar:2.16.0]
>   at 
> org.apache.camel.processor.idempotent.FileIdempotentRepository.doStart(FileIdempotentRepository.java:328)
>  ~[camel-core-2.16.0.jar:2.16.0]
> {noformat}
> The FileIdempotentRepository is trying to create the parent directory of the 
> file that was specified for the file store. If a path to the file is not 
> specified, then getParentFile() returns null. Calling .mkdirs() on that bombs.
> This route works the second time it runs because then the file exists. It 
> also works if I specify my file name as "./ids" instead of "ids".



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

[jira] [Created] (CAMEL-9367) The Apache Camel Components Poster links broken

[Rafael T C Soares (JIRA)]

Rafael T C Soares created CAMEL-9367:


 Summary: The Apache Camel Components Poster links broken
 Key: CAMEL-9367
 URL: https://issues.apache.org/jira/browse/CAMEL-9367
 Project: Camel
  Issue Type: Bug
  Components: documentation
Reporter: Rafael T C Soares


The Apache Camel Components Poster links at the end of Components page [1] 
seems to be broken. 

[1] http://camel.apache.org/components.html




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

[jira] [Commented] (CAMEL-9355) Current Throttler implementation is not accurate and does not work in a multi-threaded route

[Aaron Whiteside (JIRA)]

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

Aaron Whiteside commented on CAMEL-9355:


You are right, there is an extra thread per throttler to release the permits, 
we could make this shared, but then we would need to size the pool size 
correctly to handle any number of throttles using it.

There is actually no re-queuing happening, if a permit cannot be obtained and 
isAsyncDelayed() is enabled then the exchange is queued, the async executor 
thread pool will process the exchange's FIFO making the "async" requests block 
just like any normal thread calling the throttler with isAsyncDelayed() 
disabled. If you turn on TRACE logging you'll see how much time a exchange 
spent being queued vs blocking for a permit. But definitely async exchange's 
are not retried in any sort of loop.

> Current Throttler implementation is not accurate and does not work in a 
> multi-threaded route
> 
>
> Key: CAMEL-9355
> URL: https://issues.apache.org/jira/browse/CAMEL-9355
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.16.0
>Reporter: Aaron Whiteside
> Attachments: CAMEL_9355.patch
>
>
> Current Throttler implementation is not accurate and is even more inaccurate 
> in a multi-threaded route (think sjmsconsumerCount=100).
> The delay to sleep cannot be calculated ahead of time in a multi-threaded 
> environment, to this end the Throttler should not extend 
> DelayProcessorSupport.
> Attached is a patch that changes throttler to use a Semaphore to do accurate 
> and multi-thread safe throttling.
> The code I think is much cleaner, smaller and easier to understand. Than it 
> used to be before.
> Unit tests still pass, I had to make some changes to ThrottlerTest as it made 
> assumptions about the implementation and was doing bad things like adding a 
> 750ms buffer to validating the minimum throttle delay.. ThrottlerTest is now 
> very sane.
> I've also implemented support to allow the throttler construct to be used 
> without any nested outputs. For example the follow code is now valid.
> {code}
> 100 
> {code}
> If you want to disable this feature it can be done in 
> ThrottlerDefinition::createProcessor() line 82 changing false to true.
> I think this allows more flexible usage of the throttler, in my use case I 
> want to delay the further execution of the route, and I don't want to have to 
> split my routes up into separate sub-routes to be able to do that. 



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

[jira] [Commented] (CAMEL-9340) FileIdempotentRepository fails to create fileStore when no path is specified

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9340:
---

Github user snurmine closed the pull request at:

https://github.com/apache/camel/pull/698


> FileIdempotentRepository fails to create fileStore when no path is specified
> 
>
> Key: CAMEL-9340
> URL: https://issues.apache.org/jira/browse/CAMEL-9340
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.0
>Reporter: Ken Geis
>Priority: Trivial
> Fix For: 2.16.2, 2.17.0
>
>
> I create a FileIdempotentRepository like this:
> {code}
> .idempotentConsumer(fileIdempotentRepository(new File('ids'))) {
> it.in.body.id
> }
> {code}
> I get an error, and I traced it to:
> {noformat}
> Caused by: java.lang.NullPointerException: null
>   at 
> org.apache.camel.processor.idempotent.mpotentRepository.loadStore(FileIdempotentRepository.java:293)
>  ~[camel-core-2.16.0.jar:2.16.0]
>   at 
> org.apache.camel.processor.idempotent.FileIdempotentRepository.doStart(FileIdempotentRepository.java:328)
>  ~[camel-core-2.16.0.jar:2.16.0]
> {noformat}
> The FileIdempotentRepository is trying to create the parent directory of the 
> file that was specified for the file store. If a path to the file is not 
> specified, then getParentFile() returns null. Calling .mkdirs() on that bombs.
> This route works the second time it runs because then the file exists. It 
> also works if I specify my file name as "./ids" instead of "ids".



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

[jira] [Commented] (CAMEL-9355) Current Throttler implementation is not accurate and does not work in a multi-threaded route

[Aaron Whiteside (JIRA)]

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

Aaron Whiteside commented on CAMEL-9355:


The problem we are seeing with the current throttler, is that with a single 
thread we are never quite able to reach the actual throttle limit, and with 
multiple threads in a route we end up going over the throttle limit. For our 
business use-case this is disastrous, we're not able to meeting any of our 
SLAs. 

With the semaphore based implementation requests are not actually spread evenly 
over the time period, as you can consume say a throttle rate of 100/s in the 
first 1ms then be blocked for the remaining 999ms.

Another benefit of the semaphore implementation is that it's not based on a 
relative point of time reference. For example: the senders time slot starts at 
6 seconds past the minute, vs the receivers time slot starts at 4 seconds past 
the minute- assuming the clocks are synchronized. This can lead to the receiver 
rejecting requests because they exceed his throttle, when from the senders 
point of view he has not exceeded the throttle.

Of course this depends on how the receiver calculates received throughput. But 
it is always better to use a rolling window of the last "time period" (Eg. 1s), 
relative to the current time/current request. It may not be obvious at first 
but the semaphore is a rolling window of time.

When using a semaphore it's not really possible to have the permit be released 
without using another thread. There are other approaches but they suffer from 
the problem of assuming the time period window starts at some fixed time 
relative to them and have the issues mentioned above, or have very high 
overheads.

Such an approach, that was not a semaphore, we were using a few years ago was a 
throttling implementation based on a sentinel (head and tail are the same 
object) linked list. Where we would add items to this queue with a timestamp 
and then when checking if we exceeded the throttle, we would count back through 
the items until we exceeded our throttle or reached a timestamp outside our 
time period (again relative to the current time of the request). This achieved 
the goal but was quite expensive, as we could end up looping over 
o(throttle_rate) items, per requesting thread, to see if we were within our 
throttle rate. With a high throttle rate and high concurrency this became a 
bottle neck. Not to mention that you cannot just let the list grow unchecked, 
it had to be pruned either with a dedicated thread or delegating the work to 
each calling thread, slowing them down even more.

If this change is too radical, would you consider a throttler2 implementation, 
living along side the original throttler?



> Current Throttler implementation is not accurate and does not work in a 
> multi-threaded route
> 
>
> Key: CAMEL-9355
> URL: https://issues.apache.org/jira/browse/CAMEL-9355
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.16.0
>Reporter: Aaron Whiteside
> Attachments: CAMEL_9355.patch
>
>
> Current Throttler implementation is not accurate and is even more inaccurate 
> in a multi-threaded route (think sjmsconsumerCount=100).
> The delay to sleep cannot be calculated ahead of time in a multi-threaded 
> environment, to this end the Throttler should not extend 
> DelayProcessorSupport.
> Attached is a patch that changes throttler to use a Semaphore to do accurate 
> and multi-thread safe throttling.
> The code I think is much cleaner, smaller and easier to understand. Than it 
> used to be before.
> Unit tests still pass, I had to make some changes to ThrottlerTest as it made 
> assumptions about the implementation and was doing bad things like adding a 
> 750ms buffer to validating the minimum throttle delay.. ThrottlerTest is now 
> very sane.
> I've also implemented support to allow the throttler construct to be used 
> without any nested outputs. For example the follow code is now valid.
> {code}
> 100 
> {code}
> If you want to disable this feature it can be done in 
> ThrottlerDefinition::createProcessor() line 82 changing false to true.
> I think this allows more flexible usage of the throttler, in my use case I 
> want to delay the further execution of the route, and I don't want to have to 
> split my routes up into separate sub-routes to be able to do that. 



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

[jira] [Commented] (CAMEL-9340) FileIdempotentRepository fails to create fileStore when no path is specified

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9340:
---

GitHub user snurmine opened a pull request:

https://github.com/apache/camel/pull/699

CAMEL-9340

CAMEL-9340: Using file from user.dir as default parent file for fileStore 
file when fileStore file has no parent file.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/snurmine/camel CAMEL-9340

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/699.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #699






> FileIdempotentRepository fails to create fileStore when no path is specified
> 
>
> Key: CAMEL-9340
> URL: https://issues.apache.org/jira/browse/CAMEL-9340
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.16.0
>Reporter: Ken Geis
>Priority: Trivial
> Fix For: 2.16.2, 2.17.0
>
>
> I create a FileIdempotentRepository like this:
> {code}
> .idempotentConsumer(fileIdempotentRepository(new File('ids'))) {
> it.in.body.id
> }
> {code}
> I get an error, and I traced it to:
> {noformat}
> Caused by: java.lang.NullPointerException: null
>   at 
> org.apache.camel.processor.idempotent.mpotentRepository.loadStore(FileIdempotentRepository.java:293)
>  ~[camel-core-2.16.0.jar:2.16.0]
>   at 
> org.apache.camel.processor.idempotent.FileIdempotentRepository.doStart(FileIdempotentRepository.java:328)
>  ~[camel-core-2.16.0.jar:2.16.0]
> {noformat}
> The FileIdempotentRepository is trying to create the parent directory of the 
> file that was specified for the file store. If a path to the file is not 
> specified, then getParentFile() returns null. Calling .mkdirs() on that bombs.
> This route works the second time it runs because then the file exists. It 
> also works if I specify my file name as "./ids" instead of "ids".



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

[jira] [Created] (CAMEL-9368) Netty4 producer hangs when connection is prematurely closed

[Jonathan Anstey (JIRA)]

Jonathan Anstey created CAMEL-9368:
--

 Summary: Netty4 producer hangs when connection is prematurely 
closed
 Key: CAMEL-9368
 URL: https://issues.apache.org/jira/browse/CAMEL-9368
 Project: Camel
  Issue Type: Bug
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
 Fix For: 2.17.0


Netty4 producer is reusing connections and implementing a request-response 
style protocol. If the server closes socket connection after reading request 
packet and prior to sending back response packet, Netty4 producer hangs. If, on 
the other hand, the server closes socket after sending back response and does 
not bother to read next request, then producer does not hang.



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

[jira] [Updated] (CAMEL-9369) Acknowledge messages for RabbitMQ InOut exchange when transferring exception

[E Wong (JIRA)]

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

E Wong updated CAMEL-9369:
--
Attachment: CamelRabbitmqPatch.txt

> Acknowledge messages for RabbitMQ InOut exchange when transferring exception
> 
>
> Key: CAMEL-9369
> URL: https://issues.apache.org/jira/browse/CAMEL-9369
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 2.16.1
>Reporter: E Wong
>Priority: Minor
> Attachments: CamelRabbitmqPatch.txt
>
>
> Currently if an exception is thrown during the processing of an InOut 
> exchange on rabbitMQ, and both transferException=true and autoAck=false, the 
> exception will be transferred back to the producer however the original 
> message will remain unacknowledged.  If the server is restarted, the 
> application will attempt to reprocess the message.
> I would like to propose a patch to include a basicAck in the rabbitMQ 
> consumer in this scenario.  I’ve chosen to use a basicAck rather than a 
> rejection given that the exception would be handled by the producer in this 
> scenario and there should be no need to deadletter/requeue the messages on 
> rabbitmq.
> More details on our setup here:
> http://camel.465427.n5.nabble.com/Messages-remain-unacknowledged-when-exception-thrown-during-RabbitMQ-InOut-td5773786.html



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

[jira] [Updated] (CAMEL-9369) Acknowledge messages for RabbitMQ InOut exchange when transferring exception

[E Wong (JIRA)]

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

E Wong updated CAMEL-9369:
--
Flags: Patch

> Acknowledge messages for RabbitMQ InOut exchange when transferring exception
> 
>
> Key: CAMEL-9369
> URL: https://issues.apache.org/jira/browse/CAMEL-9369
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 2.16.1
>Reporter: E Wong
>Priority: Minor
> Attachments: CamelRabbitmqPatch.txt
>
>
> Currently if an exception is thrown during the processing of an InOut 
> exchange on rabbitMQ, and both transferException=true and autoAck=false, the 
> exception will be transferred back to the producer however the original 
> message will remain unacknowledged.  If the server is restarted, the 
> application will attempt to reprocess the message.
> I would like to propose a patch to include a basicAck in the rabbitMQ 
> consumer in this scenario.  I’ve chosen to use a basicAck rather than a 
> rejection given that the exception would be handled by the producer in this 
> scenario and there should be no need to deadletter/requeue the messages on 
> rabbitmq.
> More details on our setup here:
> http://camel.465427.n5.nabble.com/Messages-remain-unacknowledged-when-exception-thrown-during-RabbitMQ-InOut-td5773786.html



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

[jira] [Updated] (CAMEL-9369) Acknowledge messages for RabbitMQ InOut exchange when transferring exception

[E Wong (JIRA)]

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

E Wong updated CAMEL-9369:
--
Flags:   (was: Patch)

> Acknowledge messages for RabbitMQ InOut exchange when transferring exception
> 
>
> Key: CAMEL-9369
> URL: https://issues.apache.org/jira/browse/CAMEL-9369
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-rabbitmq
>Affects Versions: 2.16.1
>Reporter: E Wong
>Priority: Minor
> Attachments: CamelRabbitmqPatch.txt
>
>
> Currently if an exception is thrown during the processing of an InOut 
> exchange on rabbitMQ, and both transferException=true and autoAck=false, the 
> exception will be transferred back to the producer however the original 
> message will remain unacknowledged.  If the server is restarted, the 
> application will attempt to reprocess the message.
> I would like to propose a patch to include a basicAck in the rabbitMQ 
> consumer in this scenario.  I’ve chosen to use a basicAck rather than a 
> rejection given that the exception would be handled by the producer in this 
> scenario and there should be no need to deadletter/requeue the messages on 
> rabbitmq.
> More details on our setup here:
> http://camel.465427.n5.nabble.com/Messages-remain-unacknowledged-when-exception-thrown-during-RabbitMQ-InOut-td5773786.html



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

[jira] [Created] (CAMEL-9369) Acknowledge messages for RabbitMQ InOut exchange when transferring exception

[E Wong (JIRA)]

E Wong created CAMEL-9369:
-

 Summary: Acknowledge messages for RabbitMQ InOut exchange when 
transferring exception
 Key: CAMEL-9369
 URL: https://issues.apache.org/jira/browse/CAMEL-9369
 Project: Camel
  Issue Type: Improvement
  Components: camel-rabbitmq
Affects Versions: 2.16.1
Reporter: E Wong
Priority: Minor


Currently if an exception is thrown during the processing of an InOut exchange 
on rabbitMQ, and both transferException=true and autoAck=false, the exception 
will be transferred back to the producer however the original message will 
remain unacknowledged.  If the server is restarted, the application will 
attempt to reprocess the message.

I would like to propose a patch to include a basicAck in the rabbitMQ consumer 
in this scenario.  I’ve chosen to use a basicAck rather than a rejection given 
that the exception would be handled by the producer in this scenario and there 
should be no need to deadletter/requeue the messages on rabbitmq.

More details on our setup here:
http://camel.465427.n5.nabble.com/Messages-remain-unacknowledged-when-exception-thrown-during-RabbitMQ-InOut-td5773786.html



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

[jira] [Commented] (CAMEL-9320) Cannot set XStream permissions on a per CamelContext basis

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9320:
---

Github user asfgit closed the pull request at:

https://github.com/apache/camel/pull/677


> Cannot set XStream permissions on a per CamelContext basis
> --
>
> Key: CAMEL-9320
> URL: https://issues.apache.org/jira/browse/CAMEL-9320
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Thomas Diesler
> Fix For: 2.16.1
>
>
> One would expect to set xstream permissions on the DataFormat associated with 
> a given CamelContext like this
> {code}
> XStreamDataFormat dataFormat = (XStreamDataFormat) 
> camelctx.resolveDataFormat("xstream");
> dataFormat.setPermissions("+" + Customer.class.getName());
> {code}  
> This approach fails however because the DefaultDataFormatResolver does not 
> cache the DataFormat instances it creates 



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

[jira] [Commented] (CAMEL-9320) Cannot set XStream permissions on a per CamelContext basis

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9320:
---

Github user asfgit closed the pull request at:

https://github.com/apache/camel/pull/678


> Cannot set XStream permissions on a per CamelContext basis
> --
>
> Key: CAMEL-9320
> URL: https://issues.apache.org/jira/browse/CAMEL-9320
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Reporter: Thomas Diesler
> Fix For: 2.16.1
>
>
> One would expect to set xstream permissions on the DataFormat associated with 
> a given CamelContext like this
> {code}
> XStreamDataFormat dataFormat = (XStreamDataFormat) 
> camelctx.resolveDataFormat("xstream");
> dataFormat.setPermissions("+" + Customer.class.getName());
> {code}  
> This approach fails however because the DefaultDataFormatResolver does not 
> cache the DataFormat instances it creates 



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