locked
WCF unreliable, just stops working..... after some seconds. RRS feed

  • Question

  • Applications just hang. This is the setup:

    * 2 applications (client and server)
    * NetNamedPipeBinding used, BOTH sides expose a service.
    * both sides call the other sides service. No callback used.

    The idea is that one app (the server) collects data and pushes it to the other app (in THIS context the "client", later acutally the server managing the data).

    Both interfaces are defined with serviceBehavior: InstanceContextMode.Single, COncurrencyMode.Reentrant, UseSynchronizatonContext = false.

    The call into the "client" from the data colelctor is as data has t obe processed AS FAST AS POSSIBLE. Basically when a data packet comes in it is queued, and a threadpool work item opened. this will take X (1024 max) queued classes and push them to the client, then check if there are more. If it runs out, it expires - after resetting a flag that makes sure another work item is queued when the next packet arrives. This way pretty often i transmit 1-3 packets in one call, sometimes 100 ;)

    Here is the point: after some time, the whole thing STOPS. It just stops. No more info provided.

    I have full tracing on. And here the crazy thing starts:

    * I have upped the max receive message size to 64*65536 and this is definitely ok for about 950is messages in one batch (all messages DO have the same size). It now hangs... with 2(!) messages to be pushed. Not any significant size compared to what passed through.
    * The svclog files contain no relevance in telling me WHY the thing is closed. Great. All I see is "PipeConnection aborted". That is it.

    Anyone ANY idea what could possibly cause that? I never had such problems with remoting - it seem, WCF is a HUGH step backward in support for the developer.
    Tuesday, October 6, 2009 3:18 PM

Answers

  • Forget it, case closed as it seems. One of my locks was not properly in place on the queue synchronization IN my object, leading in rare conditions to a case where a new message was added, but the worker thread pool did fall through (and not push them over, and also not requeue). Result: no more pushing ;)
    Tuesday, October 6, 2009 7:35 PM