On Sun, Jan 12, 2014 at 11:59 AM, serega <sergejs.melde...@sap.com> wrote:
> A related question regarding subscription API. There are several use cases.
> A single subscription to invalid queue on a running broker, the messenger
> is
> blocking
> pn_messenger_subscribe(messenger,
> "amqp://guest:guest@127.0.0.1:5772/testqueue2");
> pn_messenger_rewrite(messenger, "amqp://%/*", "$2");
> pn_messenger_set_incoming_window(messenger, 200);
> pn_messenger_set_blocking(messenger, 1);
> for(;;) {
> {
> int ret = pn_messenger_recv(messenger, -1);
> printf("after receive ret=%d\n", ret);
> ...
> program prints
> LINK ERROR (amqp:not-found) Neither a queue nor a topic is defined with
> that
> name: testqueue2
> and waits.
>
> If I set it non blocking program prints
> after receive ret=-9
> after receive ret=-9
> LINK ERROR (amqp:not-found) Neither a queue nor a topic is defined with
> that
> name: testqueue2
> after receive ret=-9
> after receive ret=-9
> ...
>
>
> The same code but with valid queue and no messages in it
> pn_messenger_subscribe(messenger,
> "amqp://guest:guest@127.0.0.1:5772/testqueue");
> also returns -9.
> after receive ret=-9
> after receive ret=-9
> ...
>
>
>
> Another use case is two subscriptions, one is valid the second is dead,
> messenger is blocking.
> .....
> read: Connection refused
> [0x100200640]:ERROR[-2] SASL header mismatch: ''
>
> send: Broken pipe
> CONNECTION ERROR connection aborted
> ......
>
> There is an error message printed, but I don't see any way to get that
> error
> programmatically in my client code. I also brought the broker up and sent
> messages to the queue, but the messenger didn't pick them up. I assume
> there
> is no any recovery logic in the messenger itself. If I bring the second
> broker down the pn_messenger_recv returns immediately with error code
> PN_STATE_ERR (-5).
>
>
> I understand that intent of the messenger is simple API and hiding all
> connection management, but there has to be either recovery logic built in
> or
> a way to communicate all errors to the client so it can take appropriate
> actions. I do test edge cases which aren't frequent, but they do happen.
>
You're right, the subscription API is a little bit overly simplistic at the
moment. In particular there is no way to cancel/access the status of
individual subscriptions, and as you point out there is no internal
recovery logic. The latter would probably be a pretty straightforward patch
to provide if that would be sufficient for your case.
--Rafael
