Unfortunately, we have only seen this issue in our production environment,
where there are large amount of incoming messages from the broker. If we
can reliably reproduce the issue, I will raise a JIRA. Some follow-up
questions:
1. Can we allocate more buffer space ourselves programmatically?
2. Could the exception in theory have caused the connection issues that I
mentioned? I.e. after the exception, the Qpid debug log showed that we
continued to receive several messages, then everything stopped, our client
applications sent some requests, but no responses came back.
The following are some excerpts from the Qpid log:
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast A>; accept-mode=0; acquire-mode=0; } to
received queue
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast A>; accept-mode=0; acquire-mode=0; } to
received queue
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast A>; accept-mode=0; acquire-mode=0; } to
received queue
2013-05-14 10:44:41 [System] debug Exception constructed: An operation on a
socket could not be performed because the system lacked sufficient buffer
space or because a queue was full.
(...\src\qpid\sys\windows\SslAsynchIO.cpp:354)
(after the exception, continues to receive...)
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast A>; accept-mode=0; acquire-mode=0; } to
received queue
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast A>; accept-mode=0; acquire-mode=0; } to
received queue
...
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast B>; accept-mode=0; acquire-mode=0; } to
received queue
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast B>; accept-mode=0; acquire-mode=0; } to
received queue
2013-05-14 10:44:41 [Client] debug Pushed {MessageTransferBody:
destination=<Client Broadcast B>; accept-mode=0; acquire-mode=0; } to
received queue
(the last broadcast message received, no more coming in, but I am pretty
there were more messages)
(some times later, we tried to send some requests)
2013-05-14 11:17:17 [Client] debug Sending to exchange <request.client>
{MessageProperties: content-length=655; correlation-id=; reply-to={ReplyTo:
exchange=response; routing-key=<response.client.response_queue1>; };
content-type=; user-id=; application-headers={}; } {DeliveryProperties:
routing-key=; }
2013-05-14 11:19:31 [Client] debug Sending to exchange <request.client>
{MessageProperties: content-length=655; correlation-id=; reply-to={ReplyTo:
exchange=response; routing-key=<response.client.response_queue1>; };
content-type=; user-id=; application-headers={}; } {DeliveryProperties:
routing-key=; }
(there were supposed to be acknowledgment or responses for the requests, but
it seems everything stopped, we could't send, nor could we receive any
responses or broadcasts from the broker)
(we brought down the client and tried to reconnect)
2013-05-14 11:26:05 [Client] debug Created connection
amqp:tcp:127.0.0.1:5672 with {}
2013-05-14 11:26:05 [Client] debug Created connection amqp:ssl:<broker
host>:<port> with {}
2013-05-14 11:26:05 [Client] debug Starting connection,
urls=[amqp:ssl:<broker host>:<port>]
2013-05-14 11:26:05 [Client] info Trying to connect to amqp:ssl:<broker
host>:<port>...
Thanks.
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Qpid-throwed-WSAENOBUFS-while-receiving-data-from-a-broker-tp7592938p7592973.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
