activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof <h4v...@gmail.com>
Subject Re: NMS AMQP Client
Date Wed, 11 Sep 2019 22:01:58 GMT
https://github.com/apache/activemq-nms-amqp/pull/31/

I tested it with qpid-jms and it seems to work fine, when .net is a
producer and java is a consumer. There is a problem however when the roles
change. We try still try to interpret object "x-opt-jms-msg-type" for the
sake of AmqpTypedObjects but when we receive java serialized payload it
breaks. Should we resign from x-opt-jms-msg-type object whatsoever?



On Wed, Sep 11, 2019 at 10:56 PM Krzysztof <h4vret@gmail.com> wrote:

> And what about AmqpTypedObjects that do not
> have "application/x-dotnet-serialized-object" nor
> "application/x-java-serialized-object" content type? Can I safely add JMS
> mapping message type to them?
>
> On Wed, Sep 11, 2019 at 9:57 PM Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
>
>> If the NMS client were to send a dotnet serialized object payload in a
>> data section carrying "application/x-dotnet-serialized-object" content
>> type, without any annotation, then it would treat that as an object
>> message on reciept based on its content type. In that direction, the
>> only issue was that it shouldnt set the AMQP JMS mapping message type
>> annotation to a clearly illegal value. It is seemingly only doing so
>> in that one case, and hence my suggestion to stop that.
>>
>> Going in the other direction, its obviously fine and expected for the
>> JMS client to set the JMS mapping annotation on a java serialized JMS
>> ObjectMessage. In that case, I'd expect the receiving NMS client to
>> disregard the annotation value being for a JMS ObjectMessage, since
>> its known that it isnt actually a JMS client to begin with, and it can
>> obviously be seen that the content type is
>> "application/x-java-serialized-object" in that case and mean it cant
>> be treated as an NMS ObjectMessage but rather as e.g a bytes message.
>>
>> I'm encouraging you not to create another annnotation because I wrote
>> those bits of the JMS client+mapping and I'm saying you dont need one
>> essentially. You can use the existing annotation where it is valid to
>> do so and/or makes sense, or use none at all in many cases, especially
>> where it is invalid such as the serialized dotnet object payload.
>>
>> Robbie
>>
>> On Wed, 11 Sep 2019 at 20:11, Krzysztof <h4vret@gmail.com> wrote:
>> >
>> > I've checked it and I can confirm, that object type messages sent by
>> > NMS-amqp, are recognized by qpid-jms as object messages, and they
>> cannot be
>> > interpreted as bytes messages with the current implementation.
>> > Unfortunately, if we skip x-opt-jms-msg-type header for them in order to
>> > let qpid-jms to fallback to byte message type, we will end up with
>> exactly
>> > the same behavior in nms. We will have to come up with the solution that
>> > satisfies both parties. My inclination would be, as Michael and myself
>> > suggested, to go with our own header and relay on fallback mechanism
>> when
>> > talking to jms.
>> >
>> > I'm open to your thoughts and suggestion, though.
>> >
>> > All the best,
>> > Krzysztof Porebski
>> >
>> > On Wed, Sep 11, 2019 at 7:01 PM <michael.andre.pearce@me.com.invalid>
>> wrote:
>> >
>> > > A nms specific one seems reasonable compromise here and would give
>> some
>> > > sort of consistency
>> > >
>> > >
>> > >
>> > >
>> > > Get Outlook for Android
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, Sep 6, 2019 at 3:43 PM +0100, "Krzysztof" <h4vret@gmail.com>
>> > > wrote:
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > I see what you mean but wouldn't it be a bit strange if we skipped
>> this
>> > > stamp for this particular type of message and left it for other
>> types. If
>> > > we change the annotation to nms specific we could keep messages
>> consistent,
>> > > and as you pointed out, jms would be still able to infer types from
>> the
>> > > content of the payload.
>> > >
>> > > I'm not implying that this is the best solution, just thinking out
>> loud.
>> > >
>> > > On Fri, Sep 6, 2019 at 4:27 PM Robbie Gemmell
>> > > wrote:
>> > >
>> > > > They arent really interoperable overall and thats fine, its just the
>> > > > specific manner in this case which would be the issue...since the
>> NMS
>> > > > client seems like it would stamp its object message with an
>> annotation
>> > > > saying the contents are a JMS ObjectMessage when it clearly isn't.
>> > > >
>> > > > I'm not saying the NMS client needs its own annotation, just that
it
>> > > > shouldnt explicitly set the one from the JMS mapping in a clearly
>> > > > invalid manner (as it appears it would in this case) and so should
>> > > > instead omit the annotation in that case.
>> > > >
>> > > > Robbie
>> > > >
>> > > > On Fri, 6 Sep 2019 at 14:47, Krzysztof  wrote:
>> > > > >
>> > > > > Hi Robbie,
>> > > > >
>> > > > > I assumed, maybe too preemptively, that object messages shouldn't
>> be
>> > > > > interoperable between jms and nms as JVM and CLR are not binary
>> > > > compatible.
>> > > > >
>> > > > > Regarding to "x-opt-jms-msg-type" annotations, are you inclining
>> that
>> > > it
>> > > > > might be a better idea to introduce our own annotations for nms,
>> e.i.
>> > > > > "x-opt-nms-msg-type"?
>> > > > >
>> > > > > Thanks,
>> > > > > Krzysztof Porebski
>> > > > >
>> > > > > On Fri, Sep 6, 2019 at 12:58 PM
>> > > > wrote:
>> > > > >
>> > > > > > I think youre right there. We have ability to check a .net
>> producer
>> > > and
>> > > > > > java consumer. Will check it out quick.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Thanks for looking over
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Get Outlook for Android
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Fri, Sep 6, 2019 at 11:00 AM +0100, "Robbie Gemmell"
<
>> > > > > > robbie.gemmell@gmail.com> wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > I was having a look at the readme, which then lead to me
having
>> a
>> > > poke
>> > > > > > around the repo for the ObjectMessage handling based on
>> something I
>> > > > > > read. I think there may be an issue in the object message
>> handling
>> > > and
>> > > > > > would propose a change if its actually doing what some of
the
>> code
>> > > > > > suggests. I could be entirely wrong here though, I havent
run
>> it up
>> > > to
>> > > > > > be sure as I dont have the environment or clue to do so,
so
>> thought
>> > > > > > I'd mention this here for now rather than e.g a JIRA.
>> > > > > >
>> > > > > > It appeared that the client will always set the
>> x-opt-jms-msg-type
>> > > > > > annotation on messages, presumably with aim of increased
>> > > > > > interoperability with receiving JMS AMQP clients, which
is
>> generally
>> > > > > > fine (though the JMS client handles most cases without that
>> through
>> > > > > > other means). However in the case of object messages it
>> appeared like
>> > > > > > it might do so in a way that will specifically prevent interop
>> at all
>> > > > > > by default. It looked like it will send a Data section with
>> > > serialized
>> > > > > > object content and a "application/x-dotnet-serialized-object"
>> content
>> > > > > > type, which all seems fine and expected, but it also looked
>> like it
>> > > > > > will still set the x-opt-jms-msg-type value set for a JMS
>> > > > > > ObjectMessage type at the same time. It doesnt feel like
that
>> should
>> > > > > > be the case here, given the payload is known to be incompatible
>> and
>> > > > > > the JMS client wont be able to return such content to an
>> application.
>> > > > > > Omitting the annotation when sending such serialized dotnet
>> message
>> > > > > > payload would allow it to be treated as a BytesMessage on
a
>> receiving
>> > > > > > JMS client (due to the unknown content type) and then at
least
>> the
>> > > > > > application could retrieve the raw payload and do what it
likes
>> with
>> > > > > > it.
>> > > > > >
>> > > > > > Robbie
>> > > > > >
>> > > > > > On Fri, 6 Sep 2019 at 07:46,  wrote:
>> > > > > > >
>> > > > > > > Hi All,
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > There has been some real sterling work and collaboration
on
>> > > updating
>> > > > the
>> > > > > > .NET client offering, with some of our .net community
>> progressing the
>> > > > NMS
>> > > > > > AMQP client, and is really at a great place ready for release.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > As such i will be looking to start a release early
next week.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > If any last bits and bobs need adding please pr them
if you
>> want
>> > > > them in
>> > > > > > this release.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Best
>> > > > > > >
>> > > > > > >
>> > > > > > > Mike
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Get Outlook for Android
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message