[jira] [Updated] (CAMEL-20493) camel-core: concurrency issue copying headers
[ https://issues.apache.org/jira/browse/CAMEL-20493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-20493: - Affects Version/s: 4.0.3 > camel-core: concurrency issue copying headers > - > > Key: CAMEL-20493 > URL: https://issues.apache.org/jira/browse/CAMEL-20493 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 4.0.3, 4.4.0, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.x > > Attachments: concurrency-issue.txt > > > It looks like under some rare circumstances the copy of message headers can > suffer from concurrency issues. > Please look at the attached log, extracted from an execution of the test > JmsProducerConcurrentWithReplyTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20493) camel-core: concurrency issue copying headers
[ https://issues.apache.org/jira/browse/CAMEL-20493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835430#comment-17835430 ] John Yin commented on CAMEL-20493: -- I am seeing a similar issue in 4.0.3, with a different stacktrace, not sure whether they are related: java.util.ConcurrentModificationException: null at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1486) ~[?:?] at java.util.TreeMap$EntryIterator.next(TreeMap.java:1522) ~[?:?] at java.util.TreeMap$EntryIterator.next(TreeMap.java:1517) ~[?:?] at java.util.TreeMap.buildFromSorted(TreeMap.java:2879) ~[?:?] at java.util.TreeMap.buildFromSorted(TreeMap.java:2871) ~[?:?] at java.util.TreeMap.buildFromSorted(TreeMap.java:2871) ~[?:?] at java.util.TreeMap.buildFromSorted(TreeMap.java:2828) ~[?:?] at java.util.TreeMap.putAll(TreeMap.java:319) ~[?:?] at org.apache.camel.support.MessageSupport.copyFromWithNewBody(MessageSupport.java:231) ~[camel-support-4.0.3.jar:4.0.3] at org.apache.camel.support.MessageSupport.copyFrom(MessageSupport.java:193) ~[camel-support-4.0.3.jar:4.0.3] at org.apache.camel.support.ExchangeHelper.doCopyResults(ExchangeHelper.java:351) ~[camel-support-4.0.3.jar:4.0.3] at org.apache.camel.support.ExchangeHelper.copyResults(ExchangeHelper.java:331) ~[camel-support-4.0.3.jar:4.0.3] at org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:188) [camel-seda-4.0.3.jar:4.0.3] at org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:129) [camel-seda-4.0.3.jar:4.0.3] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?] at java.lang.Thread.run(Thread.java:840) [?:?] > camel-core: concurrency issue copying headers > - > > Key: CAMEL-20493 > URL: https://issues.apache.org/jira/browse/CAMEL-20493 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 4.4.0, 4.5.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.x > > Attachments: concurrency-issue.txt > > > It looks like under some rare circumstances the copy of message headers can > suffer from concurrency issues. > Please look at the attached log, extracted from an execution of the test > JmsProducerConcurrentWithReplyTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
[
https://issues.apache.org/jira/browse/CAMEL-20660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Piergies updated CAMEL-20660:
---
Description:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring if the client is closed and recreated while an
Exchange is in flight.
Related Zulip chat discussion:
https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Azure.20Service.20Bus.20Consumer.20failing.20to.20acknowledge.20messages
was:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring if the client is closed and recreated while an
Exchange is in flight.
> camel-azure-servicebus: Consumer fails to acknowledge messages
> --
>
> Key: CAMEL-20660
> URL: https://issues.apache.org/jira/browse/CAMEL-20660
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
>Affects Versions: 4.4.0, 4.4.1, 4.5.0
>Reporter: Dylan Piergies
>Priority: Major
>
> We have observed issues with the Service Bus consumer from Camel 4.4+ where
> consumed messages are not acknowledged/completed correctly and landing in the
> dead-letter queue, despite the Exchange having successfully delivered the
> message to its destination.
> Our routes all follow the general form:
> {{from(azureServicebus(...))}}
> {{ // ...}}
> {{ .to(https(...))}}
> {{ .log("Message delivered to...");}}
> In our logs, we are seeing the message from the final {{log}} EIP and we can
> confirm that the message has been delivered to the destination service, but
> this is often followed by a log message from the
> {{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
> {{Cannot perform operation 'completed' on a disposed receiver.}}
> We then see many of these messages arriving in the DLQ, once the retry count
> is exceeded.
> The issue is difficult to create a reproduction for: it is intermittent and
> occurs most frequently during a spike in message volumes.
> The issue disappears after downgrading Camel to 4.3.0.
> Whilst we do not know the root cause for sure, we suspect this may be a
> defect of CAMEL-19262, occurring if the client is closed and recreated while
> an Exchange is in flight.
> Related Zulip chat discussion:
> https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Azure.20Service.20Bus.20Consumer.20failing.20to.20acknowledge.20messages
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
[
https://issues.apache.org/jira/browse/CAMEL-20660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Piergies updated CAMEL-20660:
---
Description:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring if the client is closed and recreated while an
Exchange is in flight.
was:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring when the logic to close and recreate the client
occurs while an Exchange is in flight.
> camel-azure-servicebus: Consumer fails to acknowledge messages
> --
>
> Key: CAMEL-20660
> URL: https://issues.apache.org/jira/browse/CAMEL-20660
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
>Affects Versions: 4.4.0, 4.4.1, 4.5.0
>Reporter: Dylan Piergies
>Priority: Major
>
> We have observed issues with the Service Bus consumer from Camel 4.4+ where
> consumed messages are not acknowledged/completed correctly and landing in the
> dead-letter queue, despite the Exchange having successfully delivered the
> message to its destination.
> Our routes all follow the general form:
> {{from(azureServicebus(...))}}
> {{ // ...}}
> {{ .to(https(...))}}
> {{ .log("Message delivered to...");}}
> In our logs, we are seeing the message from the final {{log}} EIP and we can
> confirm that the message has been delivered to the destination service, but
> this is often followed by a log message from the
> {{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
> {{Cannot perform operation 'completed' on a disposed receiver.}}
> We then see many of these messages arriving in the DLQ, once the retry count
> is exceeded.
> The issue is difficult to create a reproduction for: it is intermittent and
> occurs most frequently during a spike in message volumes.
> The issue disappears after downgrading Camel to 4.3.0.
> Whilst we do not know the root cause for sure, we suspect this may be a
> defect of CAMEL-19262, occurring if the client is closed and recreated while
> an Exchange is in flight.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
[
https://issues.apache.org/jira/browse/CAMEL-20660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Piergies updated CAMEL-20660:
---
Description:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring when the logic to close and recreate the client
occurs while an Exchange is in-flight.
was:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring when the invocation of
{{clientWrapper.complete(message).subscribeOn(...)}} executes after the logic
to close and recreate the client has been triggered some time between reading
the message and attempting to complete it.
> camel-azure-servicebus: Consumer fails to acknowledge messages
> --
>
> Key: CAMEL-20660
> URL: https://issues.apache.org/jira/browse/CAMEL-20660
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
>Affects Versions: 4.4.0, 4.4.1, 4.5.0
>Reporter: Dylan Piergies
>Priority: Major
>
> We have observed issues with the Service Bus consumer from Camel 4.4+ where
> consumed messages are not acknowledged/completed correctly and landing in the
> dead-letter queue, despite the Exchange having successfully delivered the
> message to its destination.
> Our routes all follow the general form:
> {{from(azureServicebus(...))}}
> {{ // ...}}
> {{ .to(https(...))}}
> {{ .log("Message delivered to...");}}
> In our logs, we are seeing the message from the final {{log}} EIP and we can
> confirm that the message has been delivered to the destination service, but
> this is often followed by a log message from the
> {{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
> {{Cannot perform operation 'completed' on a disposed receiver.}}
> We then see many of these messages arriving in the DLQ, once the retry count
> is exceeded.
> The issue is difficult to create a reproduction for: it is intermittent and
> occurs most frequently during a spike in message volumes.
> The issue disappears after downgrading Camel to 4.3.0.
> Whilst we do not know the root cause for sure, we suspect this may be a
> defect of CAMEL-19262, occurring when the logic to close and recreate the
> client occurs while an Exchange is in-flight.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
[
https://issues.apache.org/jira/browse/CAMEL-20660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Piergies updated CAMEL-20660:
---
Description:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring when the logic to close and recreate the client
occurs while an Exchange is in flight.
was:
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring when the logic to close and recreate the client
occurs while an Exchange is in-flight.
> camel-azure-servicebus: Consumer fails to acknowledge messages
> --
>
> Key: CAMEL-20660
> URL: https://issues.apache.org/jira/browse/CAMEL-20660
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
>Affects Versions: 4.4.0, 4.4.1, 4.5.0
>Reporter: Dylan Piergies
>Priority: Major
>
> We have observed issues with the Service Bus consumer from Camel 4.4+ where
> consumed messages are not acknowledged/completed correctly and landing in the
> dead-letter queue, despite the Exchange having successfully delivered the
> message to its destination.
> Our routes all follow the general form:
> {{from(azureServicebus(...))}}
> {{ // ...}}
> {{ .to(https(...))}}
> {{ .log("Message delivered to...");}}
> In our logs, we are seeing the message from the final {{log}} EIP and we can
> confirm that the message has been delivered to the destination service, but
> this is often followed by a log message from the
> {{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
> {{Cannot perform operation 'completed' on a disposed receiver.}}
> We then see many of these messages arriving in the DLQ, once the retry count
> is exceeded.
> The issue is difficult to create a reproduction for: it is intermittent and
> occurs most frequently during a spike in message volumes.
> The issue disappears after downgrading Camel to 4.3.0.
> Whilst we do not know the root cause for sure, we suspect this may be a
> defect of CAMEL-19262, occurring when the logic to close and recreate the
> client occurs while an Exchange is in flight.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-20660) camel-azure-servicebus: Consumer fails to acknowledge messages
Dylan Piergies created CAMEL-20660:
--
Summary: camel-azure-servicebus: Consumer fails to acknowledge
messages
Key: CAMEL-20660
URL: https://issues.apache.org/jira/browse/CAMEL-20660
Project: Camel
Issue Type: Bug
Components: camel-azure
Affects Versions: 4.5.0, 4.4.1, 4.4.0
Reporter: Dylan Piergies
We have observed issues with the Service Bus consumer from Camel 4.4+ where
consumed messages are not acknowledged/completed correctly and landing in the
dead-letter queue, despite the Exchange having successfully delivered the
message to its destination.
Our routes all follow the general form:
{{from(azureServicebus(...))}}
{{ // ...}}
{{ .to(https(...))}}
{{ .log("Message delivered to...");}}
In our logs, we are seeing the message from the final {{log}} EIP and we can
confirm that the message has been delivered to the destination service, but
this is often followed by a log message from the
{{com.azure.messaging.servicebus.ServiceBusReceiverAsyncClient}} logger:
{{Cannot perform operation 'completed' on a disposed receiver.}}
We then see many of these messages arriving in the DLQ, once the retry count is
exceeded.
The issue is difficult to create a reproduction for: it is intermittent and
occurs most frequently during a spike in message volumes.
The issue disappears after downgrading Camel to 4.3.0.
Whilst we do not know the root cause for sure, we suspect this may be a defect
of CAMEL-19262, occurring when the invocation of
{{clientWrapper.complete(message).subscribeOn(...)}} executes after the logic
to close and recreate the client has been triggered some time between reading
the message and attempting to complete it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed DispositionNotificationMultipartReportEntity entity
[ https://issues.apache.org/jira/browse/CAMEL-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jono Morris updated CAMEL-20659: Description: The `contentTransferEncoding` needs to be included in the DispositionNotificationMultipartReportEntity constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an attribute that must be set via the constructor: [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] (was: The `contentTransferEncoding` needs to be included in the DispositionNotificationMultipartReportEntity constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor: [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713]) > camel-as2 - include contentTransferEncoding on parsed > DispositionNotificationMultipartReportEntity entity > - > > Key: CAMEL-20659 > URL: https://issues.apache.org/jira/browse/CAMEL-20659 > Project: Camel > Issue Type: Bug >Reporter: Jono Morris >Assignee: Jono Morris >Priority: Minor > > The `contentTransferEncoding` needs to be included in the > DispositionNotificationMultipartReportEntity constructor when parsing the > entity body. Previously this was set via a 'setter' but with the upgrade to > Apache HTTP client v5 it was changed to an attribute that must be set via the > constructor: > [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed DispositionNotificationMultipartReportEntity entity
[ https://issues.apache.org/jira/browse/CAMEL-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jono Morris updated CAMEL-20659: Description: The `contentTransferEncoding` needs to be included in the DispositionNotificationMultipartReportEntity constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor: [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] (was: The `contentTransferEncoding` needs to be included in the DispositionNotificationMultipartReportEntity constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor. [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713]) > camel-as2 - include contentTransferEncoding on parsed > DispositionNotificationMultipartReportEntity entity > - > > Key: CAMEL-20659 > URL: https://issues.apache.org/jira/browse/CAMEL-20659 > Project: Camel > Issue Type: Bug >Reporter: Jono Morris >Assignee: Jono Morris >Priority: Minor > > The `contentTransferEncoding` needs to be included in the > DispositionNotificationMultipartReportEntity constructor when parsing the > entity body. Previously this was set via a 'setter' but with the upgrade to > Apache HTTP client v5 it was changed to an immutable attribute that must be > set via the constructor: > [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed DispositionNotificationMultipartReportEntity entity
[ https://issues.apache.org/jira/browse/CAMEL-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jono Morris updated CAMEL-20659: Summary: camel-as2 - include contentTransferEncoding on parsed DispositionNotificationMultipartReportEntity entity (was: camel-as2 - include contentTransferEncoding on parsed MultipartReportEntity entity) > camel-as2 - include contentTransferEncoding on parsed > DispositionNotificationMultipartReportEntity entity > - > > Key: CAMEL-20659 > URL: https://issues.apache.org/jira/browse/CAMEL-20659 > Project: Camel > Issue Type: Bug >Reporter: Jono Morris >Assignee: Jono Morris >Priority: Minor > > The `contentTransferEncoding` needs to be included in the > DispositionNotificationMultipartReportEntity constructor when parsing the > entity body. Previously this was set via a 'setter' but with the upgrade to > Apache HTTP client v5 it was changed to an immutable attribute that must be > set via the constructor. > [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed MultipartReportEntity entity
[ https://issues.apache.org/jira/browse/CAMEL-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jono Morris updated CAMEL-20659: Description: The `contentTransferEncoding` needs to be included in the DispositionNotificationMultipartReportEntity constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor. [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] was: The `contentTransferEncoding` needs to be included in the MDN constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor. https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713 > camel-as2 - include contentTransferEncoding on parsed MultipartReportEntity > entity > -- > > Key: CAMEL-20659 > URL: https://issues.apache.org/jira/browse/CAMEL-20659 > Project: Camel > Issue Type: Bug >Reporter: Jono Morris >Assignee: Jono Morris >Priority: Minor > > The `contentTransferEncoding` needs to be included in the > DispositionNotificationMultipartReportEntity constructor when parsing the > entity body. Previously this was set via a 'setter' but with the upgrade to > Apache HTTP client v5 it was changed to an immutable attribute that must be > set via the constructor. > [https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed MultipartReportEntity entity
[ https://issues.apache.org/jira/browse/CAMEL-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jono Morris updated CAMEL-20659: Summary: camel-as2 - include contentTransferEncoding on parsed MultipartReportEntity entity (was: camel-as2 - include contentTransferEncoding on parsed MDN entity) > camel-as2 - include contentTransferEncoding on parsed MultipartReportEntity > entity > -- > > Key: CAMEL-20659 > URL: https://issues.apache.org/jira/browse/CAMEL-20659 > Project: Camel > Issue Type: Bug >Reporter: Jono Morris >Assignee: Jono Morris >Priority: Minor > > The `contentTransferEncoding` needs to be included in the MDN constructor > when parsing the entity body. Previously this was set via a 'setter' but > with the upgrade to Apache HTTP client v5 it was changed to an immutable > attribute that must be set via the constructor. > https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed MDN entity
[ https://issues.apache.org/jira/browse/CAMEL-20659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jono Morris updated CAMEL-20659: Description: The `contentTransferEncoding` needs to be included in the MDN constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor. https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713 was:The `contentTransferEncoding` needs to be included in the MDN constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor. > camel-as2 - include contentTransferEncoding on parsed MDN entity > > > Key: CAMEL-20659 > URL: https://issues.apache.org/jira/browse/CAMEL-20659 > Project: Camel > Issue Type: Bug >Reporter: Jono Morris >Assignee: Jono Morris >Priority: Minor > > The `contentTransferEncoding` needs to be included in the MDN constructor > when parsing the entity body. Previously this was set via a 'setter' but > with the upgrade to Apache HTTP client v5 it was changed to an immutable > attribute that must be set via the constructor. > https://github.com/apache/camel/blob/camel-4.4.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/EntityParser.java#L713 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20659) camel-as2 - include contentTransferEncoding on parsed MDN entity
Jono Morris created CAMEL-20659: --- Summary: camel-as2 - include contentTransferEncoding on parsed MDN entity Key: CAMEL-20659 URL: https://issues.apache.org/jira/browse/CAMEL-20659 Project: Camel Issue Type: Bug Reporter: Jono Morris Assignee: Jono Morris The `contentTransferEncoding` needs to be included in the MDN constructor when parsing the entity body. Previously this was set via a 'setter' but with the upgrade to Apache HTTP client v5 it was changed to an immutable attribute that must be set via the constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18017) camel-as2 - Signed content in MDN gets corrupted and is not possible to validate
[
https://issues.apache.org/jira/browse/CAMEL-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835332#comment-17835332
]
Jono Morris edited comment on CAMEL-18017 at 4/9/24 10:19 AM:
--
Yes, np the patch is merged to 4.4.x
[https://github.com/apache/camel/pull/13719]. Let me know if there's anything
else we want to do here.
was (Author: jono):
Yes, np https://github.com/apache/camel/pull/13719
> camel-as2 - Signed content in MDN gets corrupted and is not possible to
> validate
>
>
> Key: CAMEL-18017
> URL: https://issues.apache.org/jira/browse/CAMEL-18017
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Affects Versions: 3.16.0
>Reporter: Ted Lundqvist
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.6.0
>
>
> When the http response with an MDN is received it is parsed to a
> MultipartSignedEntity-object.
> When the object is serialized back to an outputstream using the method
> AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed
> to be identical to the the string received in the original http-response.
> This makes it impossible to calculate an correct message-digest and the
> method MultipartSignedEntity#isValid returns false because the following
> exception is thrown:
> "org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest
> attribute value does not match calculated value"
> when calling:
> signer.verify(new
> JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
> I tried to use the AS2-client to send messeages to both IBM Datapower and
> ArcESB and it was not possible to validate the MDN from neither of them.
> A few examples of differences between the actual received string and the
> reconstructed string are (see the full examples further down):
> # The order of the fields in the disposition-notification was in the wrong
> order:
> In the original string they where ordered as follows:
> Reporting-UA
> Original-Recipient
> Final-Recipient
> Original-Message-ID
> Disposition
> Received-content-MIC
> But in the reconstructed string the field Original-Recipient had been moved
> down and was placed before Received-content-MIC.
> # Received-content-MIC returned from both Datapower and ArcESB had a space
> between the comma-sign and the algorithmId.
> In the reconstructed string the space-character was removed.
> According to the example in RFC4130
> ([https://datatracker.ietf.org/doc/html/rfc4130)] is seems as if it should be
> ok to have a space-character.
> # In the MDN from ArcESB the field Received-content-MIC the word content was
> written with a capital 'C' i.e. Received-Content-MIC.
> I'm not sure if that is valid according to the standard or not.
> The actual string received in the http-response:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Original-Recipient: rfc822; "TEST"
> Final-Recipient: rfc822; "TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically; processed
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,
> sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> The String reconstructed from the MultipartSignedEntity:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Final-Recipient: rfc822;"TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically;processed
> Original-Recipient: rfc822; "TEST"
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> In order to always being able to calculate a correct digest the original
> string that was signed should be preserved as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-20506) Google Mail Stream CloudEvent transformer
[ https://issues.apache.org/jira/browse/CAMEL-20506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-20506. -- Resolution: Fixed > Google Mail Stream CloudEvent transformer > - > > Key: CAMEL-20506 > URL: https://issues.apache.org/jira/browse/CAMEL-20506 > Project: Camel > Issue Type: Sub-task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18017) camel-as2 - Signed content in MDN gets corrupted and is not possible to validate
[
https://issues.apache.org/jira/browse/CAMEL-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835332#comment-17835332
]
Jono Morris commented on CAMEL-18017:
-
Yes, np https://github.com/apache/camel/pull/13719
> camel-as2 - Signed content in MDN gets corrupted and is not possible to
> validate
>
>
> Key: CAMEL-18017
> URL: https://issues.apache.org/jira/browse/CAMEL-18017
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Affects Versions: 3.16.0
>Reporter: Ted Lundqvist
>Assignee: Jono Morris
>Priority: Minor
> Fix For: 4.6.0
>
>
> When the http response with an MDN is received it is parsed to a
> MultipartSignedEntity-object.
> When the object is serialized back to an outputstream using the method
> AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed
> to be identical to the the string received in the original http-response.
> This makes it impossible to calculate an correct message-digest and the
> method MultipartSignedEntity#isValid returns false because the following
> exception is thrown:
> "org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest
> attribute value does not match calculated value"
> when calling:
> signer.verify(new
> JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
> I tried to use the AS2-client to send messeages to both IBM Datapower and
> ArcESB and it was not possible to validate the MDN from neither of them.
> A few examples of differences between the actual received string and the
> reconstructed string are (see the full examples further down):
> # The order of the fields in the disposition-notification was in the wrong
> order:
> In the original string they where ordered as follows:
> Reporting-UA
> Original-Recipient
> Final-Recipient
> Original-Message-ID
> Disposition
> Received-content-MIC
> But in the reconstructed string the field Original-Recipient had been moved
> down and was placed before Received-content-MIC.
> # Received-content-MIC returned from both Datapower and ArcESB had a space
> between the comma-sign and the algorithmId.
> In the reconstructed string the space-character was removed.
> According to the example in RFC4130
> ([https://datatracker.ietf.org/doc/html/rfc4130)] is seems as if it should be
> ok to have a space-character.
> # In the MDN from ArcESB the field Received-content-MIC the word content was
> written with a capital 'C' i.e. Received-Content-MIC.
> I'm not sure if that is valid according to the standard or not.
> The actual string received in the http-response:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Original-Recipient: rfc822; "TEST"
> Final-Recipient: rfc822; "TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically; processed
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,
> sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> The String reconstructed from the MultipartSignedEntity:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Final-Recipient: rfc822;"TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically;processed
> Original-Recipient: rfc822; "TEST"
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> In order to always being able to calculate a correct digest the original
> string that was signed should be preserved as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-17088) Provide a GraphQL consumer
[ https://issues.apache.org/jira/browse/CAMEL-17088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835323#comment-17835323 ] Shikhar commented on CAMEL-17088: - Hi [~davsclaus], can I work on this? > Provide a GraphQL consumer > -- > > Key: CAMEL-17088 > URL: https://issues.apache.org/jira/browse/CAMEL-17088 > Project: Camel > Issue Type: New Feature > Components: camel-graphql >Reporter: Luca Ferrari >Priority: Minor > Labels: help-wanted > > at the moment only producer is supported but there are libraries that allow > for supporting this scenario as well > [https://www.graphql-java.com/tutorials/getting-started-with-spring-boot/] > it would be interesting to offer an alternative to something like Apollo > Server based on camel, with all the possible transformation and logic that > you can apply to query and response -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-20658) camel-kafka: make the subscription logic flexible
Otavio Rodolfo Piske created CAMEL-20658: Summary: camel-kafka: make the subscription logic flexible Key: CAMEL-20658 URL: https://issues.apache.org/jira/browse/CAMEL-20658 Project: Camel Issue Type: Task Components: camel-kafka Affects Versions: 4.5.0 Reporter: Otavio Rodolfo Piske Fix For: 4.x Some users of Kafka use relatively complex subscription / assignment process that is beyond the means of our rather [simple subscription logic|https://github.com/apache/camel/blob/camel-4.5.0/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaFetchRecords.java#L291-L312]. It would be good to have a way to handle more complex assignment process in the component. -- This message was sent by Atlassian Jira (v8.20.10#820010)
