Grokbase › Groups › RabbitMQ › rabbitmq-discuss › December 2010
FAQ
When you bind a queue to "fanout" exchange, routing key can be skipped
(not provided) according to the spec. In C# client it is implemented
by providing empty value:
model.QueueBind(queue, Program.COST_QUEUE, ->""<-, false, null);
But intuitively we tend to pass "null" for parameters that are not
used. In current implementation it causes a null exception on attempt
to convert null string into array.

So either parameters must be checked for non-null constraint, or (my
preference) null should be interpreted as empty parameter.

Vadim.

==========================================================
diff -r 982a0b810bcb
projects/client/RabbitMQ.Client/src/client/impl/WireFormatting.cs
--- a/projects/client/RabbitMQ.Client/src/client/impl/WireFormatting.cs
Thu Oct 28 14:49:55 2010 +0100
+++ b/projects/client/RabbitMQ.Client/src/client/impl/WireFormatting.cs
Wed Dec 29 11:29:24 2010 -0800
@@ -236,7 +236,13 @@
}

public static void WriteShortstr(NetworkBinaryWriter writer,
string val)
- {
+ {
+ if (string.IsNullOrEmpty(val))
+ {
+ writer.Write((byte)0);
+ return;
+ }
+
byte[] bytes = Encoding.UTF8.GetBytes(val);
int len = bytes.Length;
if (len > 255)
==========================================================

--
From RFC 2631: In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT
is explicitly specified

Search Discussions

  • Matthew Sackman at Dec 29, 2010 at 8:46 pm ⇧

    On Wed, Dec 29, 2010 at 11:30:48AM -0800, Vadim Chekan wrote:
    So either parameters must be checked for non-null constraint, or (my
    preference) null should be interpreted as empty parameter.
    Yeah, sadly there are many such cases in both the C# and Java clients of
    this kinda thing. The one that annoys me the most is in the Java client
    in queueDeclare - the queue name must be "" rather than null, but the
    arguments map can be null. Grrrr.

    All of these need fixing - there are many such odd idiosyncratic aspects
    to the Java and .Net clients but I've no idea whether these are
    scheduled to be fixed in the short, medium or long term.

    Thanks for the patch though.

    Matthew
  • Matthias Radestock at Jan 19, 2011 at 8:14 am ⇧

    Matthew Sackman wrote:
    On Wed, Dec 29, 2010 at 11:30:48AM -0800, Vadim Chekan wrote:
    So either parameters must be checked for non-null constraint, or (my
    preference) null should be interpreted as empty parameter.
    Yeah, sadly there are many such cases in both the C# and Java clients of
    this kinda thing. The one that annoys me the most is in the Java client
    in queueDeclare - the queue name must be "" rather than null, but the
    arguments map can be null. Grrrr.
    There is a method to the madness...

    The AMQP encoding of properties distinguishes between a null string and
    an absent string. While that distinction does not apply to AMQP method
    parameters, for consistency it might be desirable to apply the same
    principle there, and since all method parameters are mandatory a null
    value should not then be permitted. An NPE might not be the best way to
    complain about that though. Also, it does cause a problem for argument
    maps since the literal notation for an empty map is quite cumbersome. So
    as a matter of convenience, equating null with empty might be the better
    option.
    All of these need fixing - there are many such odd idiosyncratic aspects
    to the Java and .Net clients
    What other idiosyncratic aspects were you thinking of?


    Matthias.
  • Matthew Sackman at Jan 19, 2011 at 11:32 am ⇧

    On Wed, Jan 19, 2011 at 08:14:59AM +0000, Matthias Radestock wrote:
    Matthew Sackman wrote:
    On Wed, Dec 29, 2010 at 11:30:48AM -0800, Vadim Chekan wrote:
    So either parameters must be checked for non-null constraint, or (my
    preference) null should be interpreted as empty parameter.
    Yeah, sadly there are many such cases in both the C# and Java clients of
    this kinda thing. The one that annoys me the most is in the Java client
    in queueDeclare - the queue name must be "" rather than null, but the
    arguments map can be null. Grrrr.
    There is a method to the madness...

    The AMQP encoding of properties distinguishes between a null string
    and an absent string. While that distinction does not apply to AMQP
    method parameters, for consistency it might be desirable to apply
    the same principle there, and since all method parameters are
    mandatory a null value should not then be permitted. An NPE might
    not be the best way to complain about that though.
    Right, and I'm not sure it's desirable to reflect such properties of the
    binary codec in the Java API.
    All of these need fixing - there are many such odd idiosyncratic aspects
    to the Java and .Net clients
    What other idiosyncratic aspects were you thinking of?
    Oh things like arrays may not be used for arrays. They have to be lists.
    See writeArray in ValueWriter. Somewhat annoying when you have to do
    things like

    Map<String, Object> args = new HashMap<String, Object>();
    args.put("my-key", Arrays.asList(new String [] {"foo", "bar", "baz"}));
    String queueName =
    channel.queueDeclare("", true, true, false, args).getQueue();

    Matthew

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedDec 29, '10 at 7:30p
activeJan 19, '11 at 11:32a
posts4
users3
websiterabbitmq.com
irc#rabbitmq

3 users in discussion

Matthew Sackman: 2 posts Matthias Radestock: 1 post Vadim Chekan: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase