Hi Fraser,
I tried to reproduce it but havent succeeded. Having following code snippet:
Properties properties = new Properties();
properties.setProperty("java.naming.factory.initial",
"org.apache.qpid.jndi.PropertiesFileInitialContextFactory");
properties.setProperty("connectionfactory." + "qpidConnectionfactory",
"amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672?sasl_mechs='PLAIN''");
Context ctx = new InitialContext(properties);
ConnectionFactory conFac = (ConnectionFactory)
ctx.lookup("qpidConnectionfactory");
Connection connection = conFac.createConnection("guest", "guest");
Destination destination = new AMQAnyDestination(address);
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
BytesMessage msg = session.createBytesMessage();
for (int i=0; i<msgSize; i++)
msg.writeChar('A');
MessageProducer prod = session.createProducer(destination);
log.info("Before send");
prod.send(msg);
log.info("After send");
connection.close();
log.info("After close");
and running it for various msgSize, I saw no exception being raised :-/
I guess there have to be something more (configuration-specific)..
Kind regards,
Pavel
----- Original Message -----
> From: "Fraser Adams" <[email protected]>
> To: [email protected]
> Sent: Friday, May 3, 2013 9:17:05 AM
> Subject: Exception when calling close - Java client/C++ broker.
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
