Error when closing the socket on the client about fleck HOT 14 CLOSED

I'd second this issue. It's possible to crash server from the client side and have aforementioned exception (sorry, no repro).

from fleck.

I second this issue also

from fleck.

I second this issue too.

from fleck.

Please give this a try to check whether the issue has been resolved or not:
#27

from fleck.

Hi

I observe still the same problem also with your implementation.
Connection establishment and message passing works fine.
As soon I close Firefox I get an exception, see screenshot.
I use Windows 7, and Firefox 8.0.1.

Beni

-----Ursprüngliche Nachricht-----
Von: Ernst Naezer [mailto:[email protected]]
Gesendet: Mittwoch, 23. November 2011 12:15
An: Loesch Benjamin
Betreff: Re: [Fleck] Error when closing the socket on the client (#18)

Please give this a try to check if the issue has been resolved:
#27

Reply to this email directly or view it on GitHub:
#18 (comment)

from fleck.

That did not fix the issue for me
On Nov 23, 2011 6:14 AM, "Ernst Naezer" <
[email protected]>
wrote:

Please give this a try to check if the issue has been resolved:
#27

---

Reply to this email directly or view it on GitHub:
#18 (comment)

from fleck.

I've added a second layer of checks and removed the duplicate OnFaulted callback. Firefox now seems play nice but I'm not sure what the second Fault handler on the task object is doing differently then first one. Perhaps Statianzo can elaborate a bit on that?

from fleck.

The two OnFaulted handlers are for different purposes.

var task = Task.Factory.FromAsync<int>(begin, _stream.EndRead, null);
task.ContinueWith(t => callback(t.Result), TaskContinuationOptions.NotOnFaulted)
    .ContinueWith(t => error(t.Exception), TaskContinuationOptions.OnlyOnFaulted);
task.ContinueWith(t => error(t.Exception), TaskContinuationOptions.OnlyOnFaulted);

The chained ContinueWith handles exceptions thrown in callback. The second handles exceptions thrown from _stream.EndRead.

Not having the second ContinueWith will cause EndRead exceptions to get swallowed.

from fleck.

right,. that makes a lot of sense!

On Wed, Nov 23, 2011 at 22:30, Jason Staten
[email protected]
wrote:

The two OnFaulted handlers are for different purposes.

   var task = Task.Factory.FromAsync(begin, _stream.EndRead, null);
   task.ContinueWith(t => callback(t.Result), TaskContinuationOptions.NotOnFaulted)
       .ContinueWith(t => error(t.Exception), TaskContinuationOptions.OnlyOnFaulted);
   task.ContinueWith(t => error(t.Exception), TaskContinuationOptions.OnlyOnFaulted);

The chained ContinueWith handles exceptions thrown in callback. The second handles exceptions thrown from _stream.EndRead.

Not having the second ContinueWith will cause EndRead exceptions to get swallowed.

---

Reply to this email directly or view it on GitHub:
#18 (comment)

from fleck.

I found that out the hard way when Fleck was silently failing.

What I might suggest looking into is handling AggregateException containing ObjectDisposedException in the error handlers of Send/Receive. No matter how many IsConnected style checks are put in before the Read/Write calls, there's still the possibility of of an ObjectDisposed due to the asynchronous operation of Fleck.

The other possibility is using CancellationTokens for the tasks. Not sure if that could prevent all ObjectDisposeds though.

I apologize for not getting to this. I've been swamped.

from fleck.

hi guys,

I've had some time to look into this issue again and I've added a separate function to run the async code that catches the disposed & IO exceptions. Please feel free to take a look at this commit and give it a try.

https://github.com/enix/Fleck/commit/32f0f72ac3d10862f0599f2c808727178c3b026a

from fleck.

Please test this fix out (for the ObjectDisposed, not IOException). The exceptions still get logged when verbosity is Debug, but the server shouldn't get taken down.

from fleck.

Works for me it seems
On Jan 2, 2012 6:52 PM, "Jason Staten" <
[email protected]>
wrote:

Please test this fix out (for the ObjectDisposed, not IOException). The
exceptions still get logged when verbosity is Debug, but the server
shouldn't get taken down.

---

Reply to this email directly or view it on GitHub:
#18 (comment)

from fleck.

I'm going to close this. The fix is included in 0.8.2, currently on Nuget.

from fleck.