[
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.
