Hi all,
A colleague of mine mailed me the other day with some behaviour I hadn't
come across before.
in précis he was messing about with a Java client and C++ broker (Qpid
0.18 I believe but I doubt that's relevant here).
The client was very simple: create Connection, create Session, create
MessageProducer, create ByteMessage, send message, close Connection.
What was interesting was when the message got larger.
So he sent to a persistent queue and when the message hit 1MB
(1024*1024) he got an Exception when closing. Interestingly when he
tried with a message just one octet less (1024*1024 - 1) the Exception
didn't occur.
I can't recall the exact Exception he mentioned unfortunately, but it
related to not closing cleanly.
The message did actually end up on the queue, and if he loops with
several messages all messages get sent and the issue is clearly caused
at the end during the call to close.
My response to him was that I suspected that it related to the default
behaviour of Qpid, which is to use asynchronous delivery for efficiency,
which kind of "bends" the JMS spec a little (IIRC send should block
until a broker has taken responsibility for the message and close should
block until the pending message has been delivered).
The hitting 1MB was weird, but I reckoned that it related to caching
behaviour, so below 1MB the broker has the message in cache/buffers and
the flush/sync to actual disk doesn't immediately occur, so the acks go
back to the client pretty much instantly thus close is happy, but when
it hits 1MB a disk flush occurs which hits real disk and takes longer
thus triggering the Exception due to closing while the transfer is in
progress. I might be wrong, but it feels plausible and definitely felt
like a race condition between persisting the message and closing the
connection.
What I'm not clear on is how to make such a scenario behave cleanly. I
did suggest that if he was really sending one message and closing
immediately then it might make sense to force synchronous behaviour. He
tried using sync_publish but reckons that didn't help, which surprised me.
Of course adding a delay between calling send and close makes it behave
properly, but that feels like a cop-out solution for what is clearly a
race condition.
Can anyone suggest the "correct" solution for the case where you really
want to send a (big durable) message and immediately close the connection?
One other thing, my colleague mentioned that he'd tried the same
scenario with a python client and he said that it didn't behave like this.
thoughts?
MTIA,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
