[ 
https://issues.apache.org/activemq/browse/AMQCPP-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40251
 ] 

Timothy Bish commented on AMQCPP-143:
-------------------------------------

After looking at this and the discussion on nabble I think we should go the 
route of making the read methods const and making the stream mutable.  

The reason for this is that the onMessage callback needs to keep the message 
const so that the caller can't make any changes to the payload as we will save 
the message off when a session is transactional for instance.  We don't want 
the receiver to change the message in that case since we would then redeliver 
something that's not what was originally sent if a rollback is done.  

Since the stream is really just an internal cache of where the read methods are 
at in the payload I think its ok to make it mutable. 

Comments?


> declara BytesMessage::readXXX() methods as 'const' 
> ---------------------------------------------------
>
>                 Key: AMQCPP-143
>                 URL: https://issues.apache.org/activemq/browse/AMQCPP-143
>             Project: ActiveMQ C++ Client
>          Issue Type: Improvement
>          Components: CMS Impl
>         Environment: language specific, all the platforms
>            Reporter: Matvey Aizenshtat
>            Assignee: Timothy Bish
>            Priority: Minor
>             Fix For: 2.1.1
>
>
> BytesMessage readXXX() methods (readBytes() etc) aren't 'const' since the 
> internal stream state is changed.
> But if only the stream pointer is updated, I suppose we could have another 
> solution here, i.e.
> declare inputStream field as 'mutable':
> mutable io::ByteArrayInputStream inputStream;
> In that case we could keep read methods const.
> I am requesting for that because at the moment such non-const API forces app 
> level either always deal with non-const objects or make 
> const_cast<cms::BytesMessage *>(), that's not good.
> See also:
> http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672

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

Reply via email to