You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Gordon Sim (JIRA)" <qp...@incubator.apache.org> on 2007/01/15 20:04:27 UTC
[jira] Commented: (QPID-245) Java client hangs with C++ broker
[ https://issues.apache.org/jira/browse/QPID-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464931 ]
Gordon Sim commented on QPID-245:
---------------------------------
The exception on the broker appears to be caused by the use of non-standard field table value codes in the client properties sent by the java client as part of the connection.start-ok method.
I will try and improve the error handling a little here (the code in question will likely be out of date soon due to changes in io handling and also in the move to 0.9 so I won't spend too long on that). We can of course also implement the non-standard types in c++ as well. However as that has interoperability implications it should be discussed further on the list.
It certainly seems wrong to use non-standard types for the client properties (or anywhere by default) as that would make our clients incompatible with any other implementation. Allowing applications to explicitly use non-standard behaviour is different, particularly if they are informed that doing so will cause their application to become dependent on qpid.
> Java client hangs with C++ broker
> ---------------------------------
>
> Key: QPID-245
> URL: https://issues.apache.org/jira/browse/QPID-245
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Java Client
> Environment: svn revision 491076, RHEL 4 64 bit
> Reporter: Robert Greig
>
> Run a C++ broker, and any java client.
> During the connection phase the broker emits:
> ---------------0x545a80
> St9exception
> The client outputs:
> main 2007-01-03 21:26:29,477 INFO [qpid.client.transport.SocketTransportConnection] Attempting connection to localhost/127.0.0.1:5673
> AnonymousIoService-1 2007-01-03 21:26:29,738 INFO [qpid.client.security.CallbackHandlerRegistry] Available SASL mechanisms: CRAM-MD5 PLAIN
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Gordon Sim <gs...@redhat.com>.
Gordon Sim wrote:
> Using 'long strings' only as per your suggestion allows the java clients
> to at least get through connection with the c++ broker at present (see
> attached patch; not sure if this will have an impact on JMS compliance).
> However the topic test still doesn't complete due to use of other
> non-standard types (in particular the 'binary' type, though I need to do
> some more investigation into this as the topic test code itself does not
> seem to set any message properties).
Just to wrap this up, binary property value is the destination url set
in BasicMessageConsumer. Robert has I believe checked in (temporary
changes to allow the java topic test to run over the c++ broker).
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> I agree that interop is a key principle and very important. However in
> the case of 0.8 which, when you get into the detail of features
> required for JMS or even just "useful functionality" and realise that
> 0.8 has many limitations, I think it's reasonable to break interop as
> long as we push the changes into AMQP.
I agree 0-8 has many limitations (some, like richer types are still
there in 0-9). Again, I'm not at all opposed to addressing these with
non-standard features, but I would be keen to explore whether these can
be provided in such a way as to allow basic functionality to remain
interoperable while allowing users to sacrifice that interoperability
where the more advanced features are needed.
> Yes I completely agree, and accept that we (mostly me) have not done a
> particularly good job of publicising the breaking changes. Hopefully
> now that AMQP is improving its process, it will be easier to follow
> through on these.
No criticism of individuals was in any way intended when I made my
comments in JIRA or in the subsequent email thread. My aim was merely to
highlight the issue at hand which led into a brief diversion on approach
that we seem to be in agreement on.
Using 'long strings' only as per your suggestion allows the java clients
to at least get through connection with the c++ broker at present (see
attached patch; not sure if this will have an impact on JMS compliance).
However the topic test still doesn't complete due to use of other
non-standard types (in particular the 'binary' type, though I need to do
some more investigation into this as the topic test code itself does not
seem to set any message properties).
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Robert Greig <ro...@gmail.com>.
On 16/01/07, Gordon Sim <gs...@redhat.com> wrote:
> Standardising on some scheme of mapping JMS property values to AMQP
> field table values is required for interoperability between two
> different JMS adapters, but providing the standard values are used (and
> e.g. selectors aren't required) any compliant AMQP broker could be used
> between them without it caring about that mapping.
If you mean we could have done it using name mangling plus "long str"
encoding then yes that is certainly true.
> I know that at present there are not many implementations of AMQP to
> choose from so this is a somewhat theoretical and pedantic point but the
> principle of interoperability does seem to me to be an important one.
I agree that interop is a key principle and very important. However in
the case of 0.8 which, when you get into the detail of features
required for JMS or even just "useful functionality" and realise that
0.8 has many limitations, I think it's reasonable to break interop as
long as we push the changes into AMQP.
> I think it is important for us to be
> explicit about the impact of any such features on interoperability until
> the point that they can be standardised though, and try (as far as
> possible) to provide them in such a way that we augment rather than
> break the protocol and allow basic functionality to be used even where
> such extensions are not supported by the peer.
Yes I completely agree, and accept that we (mostly me) have not done a
particularly good job of publicising the breaking changes. Hopefully
now that AMQP is improving its process, it will be easier to follow
through on these.
RG
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> On 16/01/07, Gordon Sim <gs...@redhat.com> wrote:
>
>> Any string property set on the FieldTable class in the java client gets
>> passed as a 'wide string' which is a new, non-standard type (the
>> standard 'long string' value type doesn't seem to be used anymore in
>> field table). So the strings in the client properties can't be
>> understood by a broker that doesn't support that new type.
>
> There is a method setAsciiString, which allows you to specify short
> strings. However I hadn't realised that use of setString was so
> widespread at the moment.
>
>> Perhaps as a quick fix to this particular problem we could make use of
>> the non-standard types more explicit (e.g. setWideString() on the
>> FieldTable class).
>
> Yes, or I was going to change field table for the moment to use
> non-wide strings all the time (until we get the types approved and
> implemented in C++ and python etc.).
That would probably be the best short term solution and the AMQType
implementations for the various strings seem to be more or less the same
at present anyway.
Use of (some of) the non-string property types on JMS messages would
still cause problems, but that is something we can warn about and
applications can avoid it if interoperability prior to 0-10 (or
whatever) is required.
>> As I understand it, the most urgent use of these new types is in
>> explicitly encoding the value types for all custom JMS properties. While
>> I fully appreciate the desirability of this, I would also like to keep
>> interoperability except where the application explicitly chooses to use
>> non-standard extensions.
>
> The main driver was not really strings (although the length limit on
> short string is an obvious issue) but for other types where we needed
> to know the "real" type so that we could apply the type conversion
> rules.
>
>> Maybe we could allow different strategies for mapping JMS message
>> property values to AMQP field table values. For full JMS compliance it
>> may be the non-standard approach is the most viable but many
>> applications may be able to work with other schemes e.g. transmitting
>> all properties as strings and converting them as and where necessary (I
>> realise this is not fully compliant from a JMS perspective). If the
>> strategies could be set via a system property, that would allow users to
>> trade off between AMQP compliance and JMS compliance (we could even
>> allow a name or value mangling hack where both could be supported albeit
>> in a rather nasty way).
>
> My first reaction is: is it worth spending time doing that rather than
> just getting the field table types updated in the protocol? We
> previously had a name mangling rule scheme that doesn't take you any
> further forward since you need to standardise those rules to achieve
> interop.
Standardising on some scheme of mapping JMS property values to AMQP
field table values is required for interoperability between two
different JMS adapters, but providing the standard values are used (and
e.g. selectors aren't required) any compliant AMQP broker could be used
between them without it caring about that mapping. So while name
mangling (or some other scheme) doesn't take us further forward in a
standardised JMS mapping, it would at least avoid taking a backward step
in AMQP compliance (a standard already published). For this particular
case however, I think your suggestion above is a good pragmatic approach
for now.
I know that at present there are not many implementations of AMQP to
choose from so this is a somewhat theoretical and pedantic point but the
principle of interoperability does seem to me to be an important one.
The recent addition of a field to the basic.consume method in the 0-8
spec in the repository mean that even the c++ implementation built
against that spec would be non-compliant with the published standard of
the same version (again, of little practical significance once we move
to 0-9 where that change is standardised). The addition of the
exchange.bound method on the other hand is far less of an issue as it
wouldn't break basic messaging functionality that did not require it.
I'm not at all opposed to non-standard extensions, in fact I think they
are a great way of speeding up the improvement of the standardised
protocol through a working implementation of a valuable feature (as well
as use cases showing that value). I think it is important for us to be
explicit about the impact of any such features on interoperability until
the point that they can be standardised though, and try (as far as
possible) to provide them in such a way that we augment rather than
break the protocol and allow basic functionality to be used even where
such extensions are not supported by the peer.
> I think there was general consensus that the original set of field
> table types was incomplete so it shouldn't be too difficult to get it
> approved. Martin typed up the proposal (which had originally be only
> in an email) and put it on the wiki when he was implementing the field
> table stuff:
>
> https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal
>
> RG
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Robert Greig <ro...@gmail.com>.
On 16/01/07, Gordon Sim <gs...@redhat.com> wrote:
> Any string property set on the FieldTable class in the java client gets
> passed as a 'wide string' which is a new, non-standard type (the
> standard 'long string' value type doesn't seem to be used anymore in
> field table). So the strings in the client properties can't be
> understood by a broker that doesn't support that new type.
There is a method setAsciiString, which allows you to specify short
strings. However I hadn't realised that use of setString was so
widespread at the moment.
> Perhaps as a quick fix to this particular problem we could make use of
> the non-standard types more explicit (e.g. setWideString() on the
> FieldTable class).
Yes, or I was going to change field table for the moment to use
non-wide strings all the time (until we get the types approved and
implemented in C++ and python etc.).
> As I understand it, the most urgent use of these new types is in
> explicitly encoding the value types for all custom JMS properties. While
> I fully appreciate the desirability of this, I would also like to keep
> interoperability except where the application explicitly chooses to use
> non-standard extensions.
The main driver was not really strings (although the length limit on
short string is an obvious issue) but for other types where we needed
to know the "real" type so that we could apply the type conversion
rules.
> Maybe we could allow different strategies for mapping JMS message
> property values to AMQP field table values. For full JMS compliance it
> may be the non-standard approach is the most viable but many
> applications may be able to work with other schemes e.g. transmitting
> all properties as strings and converting them as and where necessary (I
> realise this is not fully compliant from a JMS perspective). If the
> strategies could be set via a system property, that would allow users to
> trade off between AMQP compliance and JMS compliance (we could even
> allow a name or value mangling hack where both could be supported albeit
> in a rather nasty way).
My first reaction is: is it worth spending time doing that rather than
just getting the field table types updated in the protocol? We
previously had a name mangling rule scheme that doesn't take you any
further forward since you need to standardise those rules to achieve
interop.
I think there was general consensus that the original set of field
table types was incomplete so it shouldn't be too difficult to get it
approved. Martin typed up the proposal (which had originally be only
in an email) and put it on the wiki when he was implementing the field
table stuff:
https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal
RG
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> On 15/01/07, Carl Trieloff <cc...@redhat.com> wrote:
>>
>> Gordon makes a good point, additionally I expect from time to time we
>> will need to go ahead/ or do things to fix issues in the spec as we
>> develop. It is key that we bring these items to the list so that we can
>> discuss and bring them back to the AMQP Working Group for inclusion or
>> errata.
>
> I will check which properties are set in the client. I didn't think we
> set anything much beyond strings though.
>
> The Java client was updated, for the purposes of JMS compatibility, to
> use the set of field table types that I had previously submitted to
> the AMQP list. Although there was I think general agreement on
> extending the types (after lengthy debate with one person in
> particular) the proposal "fizzled out".
>
Any string property set on the FieldTable class in the java client gets
passed as a 'wide string' which is a new, non-standard type (the
standard 'long string' value type doesn't seem to be used anymore in
field table). So the strings in the client properties can't be
understood by a broker that doesn't support that new type.
Perhaps as a quick fix to this particular problem we could make use of
the non-standard types more explicit (e.g. setWideString() on the
FieldTable class).
As I understand it, the most urgent use of these new types is in
explicitly encoding the value types for all custom JMS properties. While
I fully appreciate the desirability of this, I would also like to keep
interoperability except where the application explicitly chooses to use
non-standard extensions.
Maybe we could allow different strategies for mapping JMS message
property values to AMQP field table values. For full JMS compliance it
may be the non-standard approach is the most viable but many
applications may be able to work with other schemes e.g. transmitting
all properties as strings and converting them as and where necessary (I
realise this is not fully compliant from a JMS perspective). If the
strategies could be set via a system property, that would allow users to
trade off between AMQP compliance and JMS compliance (we could even
allow a name or value mangling hack where both could be supported albeit
in a rather nasty way).
Thoughts?
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Robert Greig <ro...@gmail.com>.
On 15/01/07, Carl Trieloff <cc...@redhat.com> wrote:
>
> Gordon makes a good point, additionally I expect from time to time we
> will need to go ahead/ or do things to fix issues in the spec as we
> develop. It is key that we bring these items to the list so that we can
> discuss and bring them back to the AMQP Working Group for inclusion or
> errata.
I will check which properties are set in the client. I didn't think we
set anything much beyond strings though.
The Java client was updated, for the purposes of JMS compatibility, to
use the set of field table types that I had previously submitted to
the AMQP list. Although there was I think general agreement on
extending the types (after lengthy debate with one person in
particular) the proposal "fizzled out".
I'll resubmit the proposal to the AMQP list once Jira has been set up
and it can actually be tracked to completion.
RG
Re: [jira] Commented: (QPID-245) Java client hangs with C++ broker
Posted by Carl Trieloff <cc...@redhat.com>.
Gordon makes a good point, additionally I expect from time to time we
will need to go ahead/ or do things to fix issues in the spec as we
develop. It is key that we bring these items to the list so that we can
discuss and bring them back to the AMQP Working Group for inclusion or
errata.
Carl.
Gordon Sim (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/QPID-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464931 ]
>
> Gordon Sim commented on QPID-245:
> ---------------------------------
>
> The exception on the broker appears to be caused by the use of non-standard field table value codes in the client properties sent by the java client as part of the connection.start-ok method.
>
> I will try and improve the error handling a little here (the code in question will likely be out of date soon due to changes in io handling and also in the move to 0.9 so I won't spend too long on that). We can of course also implement the non-standard types in c++ as well. However as that has interoperability implications it should be discussed further on the list.
>
> It certainly seems wrong to use non-standard types for the client properties (or anywhere by default) as that would make our clients incompatible with any other implementation. Allowing applications to explicitly use non-standard behaviour is different, particularly if they are informed that doing so will cause their application to become dependent on qpid.
>
>
>> Java client hangs with C++ broker
>> ---------------------------------
>>
>> Key: QPID-245
>> URL: https://issues.apache.org/jira/browse/QPID-245
>> Project: Qpid
>> Issue Type: Bug
>> Components: C++ Broker, Java Client
>> Environment: svn revision 491076, RHEL 4 64 bit
>> Reporter: Robert Greig
>>
>> Run a C++ broker, and any java client.
>> During the connection phase the broker emits:
>> ---------------0x545a80
>> St9exception
>> The client outputs:
>> main 2007-01-03 21:26:29,477 INFO [qpid.client.transport.SocketTransportConnection] Attempting connection to localhost/127.0.0.1:5673
>> AnonymousIoService-1 2007-01-03 21:26:29,738 INFO [qpid.client.security.CallbackHandlerRegistry] Available SASL mechanisms: CRAM-MD5 PLAIN
>>
>
>