[
https://issues.apache.org/jira/browse/OPENWIRE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17943700#comment-17943700
]
Christopher L. Shannon commented on OPENWIRE-79:
------------------------------------------------
I haven't started it yet so you are welcome to take a look but this is a bit
tricky as I'd like to refactor things to avoid having to use a ThreadLocal in
the future. The issue (why I had to use a ThreadLocal in AMQ-6596) is that
everything for OpenWire implements the
[DataStreamMarshaller|https://github.com/apache/activemq/blob/953737ca082e1ff67cf0b408e7ec72cd89be75ac/activemq-client/src/main/java/org/apache/activemq/openwire/DataStreamMarshaller.java]
interface.
Ideally, we would have some sort of context that would be passed around per
marshalling attempt and it could track the current size information. This could
be similar to how we have ConnectionContext for current connection information.
For example, the following method
{code:java}
int tightMarshal1(OpenWireFormat format, Object c, BooleanStream bs) throws
IOException;
{code}
could become something like
{code:java}
int tightMarshal1(MarshallingContext context, Object c, BooleanStream bs)
throws IOException;
{code}
If you look at my bug fix patch in detail from AMQ-6596 you will see what I
mean. That context could probably contain a reference to the OpenWireFormat
instead so it can be shared.
The problem is, to make the change to the interface, would then require
re-generating every single version of OpenWire. While there's no issue with
binary compatibility (older clients can still send the same packets), if we
then update the broker to use the new interface we need to have every command
and every version now use the new interface so things compile and work
correctly. OpenWire assumes that all commands use that interface so it just
dynamically loads the version so to not have it be hacky we'd need to
re-generate all the versions again to use the new interface for the java
implementation.
This is doable of course but requires updating the new generation code,
generating new versions, and then we'd need to update the broker and every spot
that uses that interface to be compatible.
> Add array size validation support from AMQ-6596
> -----------------------------------------------
>
> Key: OPENWIRE-79
> URL: https://issues.apache.org/jira/browse/OPENWIRE-79
> Project: ActiveMQ OpenWire
> Issue Type: Bug
> Reporter: Christopher L. Shannon
> Priority: Major
> Fix For: 1.0.0
>
>
> We need to add the fix from https://issues.apache.org/jira/browse/AMQ-6596
> It would be nice to rework it to avoid having to use a ThreadLocal but that
> might be hard becuase it would require changing all the interfaces and
> generated code, so newer versions of OpenWire would require a Java client or
> broker to change how they call the code. The actual commands however would
> still be binary compatible so it may be doable, it needs investigating
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
