hello,

Is this class threadsafe? I guess not because channels are not threadsafe?

Why is the routing key a final attribute? Why is it not a parameter of
primitiveCall(...)?

thx

john
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111118/b94076bd/attachment.htm>

Search Discussions

  • John doe at Nov 18, 2011 at 1:58 pm

    hello,

    Is this class threadsafe? I guess not because channels are not threadsafe?

    Why is the routing key a final attribute? Why is it not a parameter of
    primitiveCall(...)?

    thx

    john
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111118/5c11539d/attachment.htm>
  • Matthias Radestock at Nov 20, 2011 at 3:43 pm

    On 18/11/11 13:42, john doe wrote:
    Is this class threadsafe? I guess not because channels are not threadsafe? Correct.
    Why is the routing key a final attribute? Why is it not a parameter of
    primitiveCall(...)?
    The idea is that you create RpcClients to talk to specific rpc servers.
    The latter are typically identified by a combination of exchange and
    routing key.

    Matthias.
  • John doe at Nov 21, 2011 at 9:11 am
    Thank you Matthias.

    If this class is known to *not* be threadsafe, why is there a
    "synchronized" statement in primitiveCall? It somewhat confuses me.

    John

    2011/11/20 Matthias Radestock <matthias at rabbitmq.com>
    On 18/11/11 13:42, john doe wrote:

    Is this class threadsafe? I guess not because channels are not threadsafe?
    Correct.


    Why is the routing key a final attribute? Why is it not a parameter of
    primitiveCall(...)?
    The idea is that you create RpcClients to talk to specific rpc servers.
    The latter are typically identified by a combination of exchange and
    routing key.

    Matthias.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111121/71483d3a/attachment.htm>
  • Matthias Radestock at Nov 21, 2011 at 9:24 am

    On 21/11/11 09:11, john doe wrote:
    Thank you Matthias.
    If this class is known to *not* be threadsafe, why is there a
    "synchronized" statement in primitiveCall? It somewhat confuses me.
    That synchronisation is necessary for the coordination of the thread
    issuing a call with the thread on which the reply arrives.

    The code calls _channel.basicPublish, which is not threadsafe, outside
    of any synchronisation context. Hence it is not safe to issue calls from
    multiple threads or use the underlying channel in other threads.

    Matthias.
  • John doe at Nov 22, 2011 at 4:22 pm
    Ok, now I understand, thanks.

    I find strange that primitiveCall do not follow the signature of original
    functions, with exchange and routing key provided along with the message.

    I am using extensively routing facilities of amqp, and I need to manage
    thousands of clients, one per routing key (or do you think creating a
    channel and a private queue is cheap enough to be done tens of time per
    second?)

    I guess you designed this RpcClient class more as an example, to be
    customized? That's fine but code of RpcClient is not that simple and I
    would have prefered not to maintain that kind of risky low-level things...

    Would you consider putting a primitiveCall(String exchange, String
    routingKey, AMQP.BasicProperties props, byte[] message) in a future release?

    John


    2011/11/21 Matthias Radestock <matthias at rabbitmq.com>
    On 21/11/11 09:11, john doe wrote:

    Thank you Matthias.
    If this class is known to *not* be threadsafe, why is there a
    "synchronized" statement in primitiveCall? It somewhat confuses me.
    That synchronisation is necessary for the coordination of the thread
    issuing a call with the thread on which the reply arrives.

    The code calls _channel.basicPublish, which is not threadsafe, outside of
    any synchronisation context. Hence it is not safe to issue calls from
    multiple threads or use the underlying channel in other threads.

    Matthias.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111122/29ac6ca2/attachment.htm>
  • Steve Powell at Nov 23, 2011 at 12:09 pm
    Dear John,
    On 22 Nov 2011, at 16:22, john doe wrote:
    I find strange that primitiveCall do not follow the signature of original
    functions, with exchange and routing key provided along with the message.
    Well, there are a lot of strange things about this code; and it is not very
    good Java, to be honest (it calls protected methods in its constructor for one
    thing). I guess I'd like to re-write it. The protected methods seem to encourage
    you to sub-class it, for instance. In general I'm not keen on subclassing
    as a user API, unless it is very carefully controlled (as in Consumer),
    and in this case it would be easy to break things.
    I am using extensively routing facilities of amqp, and I need to manage
    thousands of clients, one per routing key (or do you think creating a channel
    and a private queue is cheap enough to be done tens of time per second?)
    The overhead of an RpcClient creation is non-trivial; but the creation of the
    private (reply)queue is essential, so that we can't get away from that. Tens of
    times a second ought to be easy, though. Creating a channel each time would
    be a serious problem -- don't do that. Multiple consumers on the same channel
    are OK (there's even a way to beef up the callback threads in 2.7.0)
    and ought to perform well.

    Having thousands of RPCs on a single channel at once might be pushing
    it, though.
    I guess you designed this RpcClient class more as an example, to be customized?
    That's fine but code of RpcClient is not that simple and I would have prefered
    not to maintain that kind of risky low-level things...
    Yes, I agree. It certainly is just an example. A simpler and cleaner one suited to
    your needs should be derived from it.
    Would you consider putting a primitiveCall(String exchange, String routingKey,
    AMQP.BasicProperties props, byte[] message) in a future release?
    Yes; but I would like to clean up RpcClient before that. I'd be delighted with
    any comments from the field.

    Steve Powell (a happy bunny)
    ----------some more definitions from the SPD----------
    avoirdupois (phr.) 'Would you like peas with that?'
    distribute (v.) To denigrate an award ceremony.
    definite (phr.) 'It's hard of hearing, I think.'
    modest (n.) The most mod.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedNov 18, '11 at 1:42p
activeNov 23, '11 at 12:09p
posts7
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2021 Grokbase