I don't think IErrorHandler would work in this case. Look at the stack
trace - you are unable to catch exception in any way since, the
connection is made in a separate thread (at least I suppose so looking
at the stack trace, specifically
We are experiencing an issue with async behaviours in sockets (with
SendAsync/callback not Begin/End).
Our visible issue is that when in a send loop we will fail on our
heartbeats. After debugging and counting calls into/out of
SendAsync/callback we see that we are inside of a call to SendAsync
I apologize, I was under the probably mistaken impression that those
EXCEPTION handling: messages were coming from the IErrorHandler he was
talking about.
-Rob
On 06/27/2012 01:16 AM, Maciej Paszta wrote:
I don't think IErrorHandler would work in this case. Look at the stack
trace - you are
Not knowing anything else, I saw that there was very recently work done
in Async Sockets, The following commit, date June 18th (about a week and
a half ago) is titled Fix Async Sockets, it's a one line change but
seems to include a unit test which would indicate they are working
properly now:
By the way, I noticed the bottom of the stack was similar to this
earlier error message we corrected:
http://mono.1490590.n4.nabble.com/Exception-at-System-ServiceModel-Channels-Http-HttpReplyChannel-TryReceiveRequest-td4649878.html
I personally believe something called *Try*ReceiveRequest should
This code:
try {
return TryReceiveRequest
(tout, out ctx);
} finally {
lock (async_result_lock) {
We've been aware of such issues, could you file a bug and attach a test
case with it please?
This would really really help us fix it.
On Wed, Jun 27, 2012 at 4:08 AM, Greg Young gregoryyou...@gmail.com wrote:
We are experiencing an issue with async behaviours in sockets (with
I sent a suggested fix, untested, under another thread, titled
BeginTryReceiveRequest and Socket error handling?. I'm more wondering
if it's a good idea or not, but it looks like it is safe to me in this
case because we're in our own thread starting there.
The Exception being raised is
Trying to get it into a testcase has been very difficult unfortunately
we only really see it at saturation levels and not commonly. Seems
like some kind of internal race condtion.
Are the begin/end calls more stable and preferable at this time?
On Wed, Jun 27, 2012 at 9:14 AM, Rodrigo Kumpera
Hello
Thanks for the suggestion and updates.
I tested the application on windows machine (in fact i am using visual
studio to develop it) and the result was that if i close the browser while
running the console application under windows the application doesn't crash
but still raise an error
On 27/06/12 14:09, Rob Wilkens wrote:
This code:
try {
return TryReceiveRequest
(tout, out ctx);
} finally {
lock
On 06/27/2012 01:21 PM, Andres G. Aragoneses wrote:
On 27/06/12 14:09, Rob Wilkens wrote:
This code:
try {
return
TryReceiveRequest
(tout, out ctx);
} finally
This looks like an entirely different kind of error than we were seeing
before. Here we are attempting, apparently, to change the content type
after we've already sent the headers, if the exception message is right,
and that sounds like a bug -- but i don't have the patience to dig
through the
On 06/27/2012 01:02 PM, shahbour wrote:
Reproducing the error is very simple, just host any application under
console app and in any service function put Thread.Sleep(..) to give
you time to close the browser before it reply. Then call this function
from any client and close it before getting
14 matches
Mail list logo
