[jira] Commented: (CAMEL-1078) Do not copy Exchanges at each step to improve performance

["Roman Kalukiewicz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51690#action_51690 ] 

Roman Kalukiewicz commented on CAMEL-1078:
------------------------------------------

So let me add my thoughts on it.

I believe Exchange don't have to be specialized and moreover messages should be not. To become consistent across all message types and components I believe we should use generic Message class that has an access to original message received from the endpoint.

This solution might have few benefits:
* Consistent look at the message independent of actual component used
** For example in JMS some headers are stored in the JMS message itself, while some in Camel's map of headers, because not every name can be used as JMS property name)
** In few cases I can retrieve a headers via getHeader(String), but they doesn't exists in the map returned by getHeaders() - I believe it was in JBI some time ago. This solution would eliminate those problems at all!
* If we keep original technology-specific message in camel exchange in read-only fashion, we can always access original request that came to the endpoint - it might be generally Object, so it can be used by any component.
** We can also keep some 'dirty' flag that can make solutions more optimal like JMS<->JMS bridge, that can detect unchanged JMS message and send it directly
** I believe because of Camel message model being not always 100% compatible with any technology we should avoid synchronizing camel message with underlying message as it is not always possible or meaningful.
** It involves marshaling/unmarshaling process when message arrives, but I would really like to keep all camel headers/body in one place - in DefaultMessage. Now when you debug, you never know ;) The only usage of subclasses of DefaultMessage I see is to delay marshaling/unmarshaling process like lazy-creating body or headers map when you retrieve them.
* And my beloved topic about one message per exchange - no in/out/fault distinction, but it is different story ;)

I know that all those things can be (in majority) fixed by tailing bugs, but simplification of the concept itself seems to be more bug-proof ;)

Maybe not all of those things should be targeted for 2.0, but those are my thoughts on Camel message model ;)

> Do not copy Exchanges at each step to improve performance
> ---------------------------------------------------------
>
>                 Key: CAMEL-1078
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1078
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 1.5.0
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>            Priority: Critical
>             Fix For: 2.1.0
>
>
> The code in DefaultEndpoint.createExchange(Exchange exchange), calls on getExchangeType() to figure out if a new copy of Exchange needs be created.  The code relies though on the generic argument of the Endpoint type to figure out the actual Exchange type.  With the generics removed part of CAMEL-872, getExchangeType() always returns null, forcing a copy every time.
> There is no real need to extend Exchange, so the proposal for this to make the Exchange final and move the component specific bits, if any,  in the Message.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.