WCF timeout

[Bodekaer]

Hey @amaitland,

If you have the app running for a while, and idling for e.g. 5 minutes (not sure exactly how long), then we get the error below:

An exception of type 'System.ServiceModel.CommunicationObjectAbortedException' occurred in mscorlib.dll but was not handled in user code

Additional information: The operation 'EvaluateScript' could not be completed because the sessionful channel timed out waiting to receive a message. To increase the timeout, either set the receiveTimeout property on the binding in your configuration file, or set the ReceiveTimeout property on the Binding directly.

Any tips/recommendations on how to fix this?
I'm using the latest build you have from today.

[Bodekaer]

Here is the error line info: CefSharp.dll!CefSharp.Internals.BrowserProcessServiceHost.EvaluateScriptAsync.AnonymousMethod__4(System.Threading.Tasks.Task<System.ServiceModel.OperationContext> t) Line 58 BrowserProcessServiceHost.cs

Direct link:
https://github.com/cefsharp/CefSharp/blob/JsBinding_WIP/CefSharp/Internals/BrowserProcessServiceHost.cs#L58

[amaitland]

I'm guessing the WCF callback channel has some sort of idle timeout, a quick google and it appears other people have similar issues. It may take a little tinkering to sort out.

This looks like the most promising article I could find so far:

http://suriyanto.blogspot.com.au/2007/12/idle-timeout-for-named-pipe-binding.html

[Bodekaer]

👍 Looks like that's just it yes.
Let me know if you're too busy at the moment, and I can try to make a patch today.

[amaitland]

Patch would be greatly appreciated 😄

[Bodekaer]

Here you go:
https://github.com/Bodekaer/CefSharp/commit/fbc5bf970a720677f8bb5cceb08eeee4d9e5b488.patch

I'm no WCF expert, so please double check :)
See diff here: MailbirdInc@fbc5bf9

[amaitland]

@Bodekaer Thanks, did it solve your timeout problem?

[Bodekaer]

Yep. Have not failed since i applied this yesterday.
We probably still need to add error handling if the channel fails for other reasons than timeout.
I read that the channel closes as soon as any error is raised, requiring that we handle it and re-open the connection.

I have not yet experienced this problem though, so we can just close this issue and I'll open a separate issue once I can find a good way to replicate a failed connection.

[amaitland]

Excellent, I'll merge the change in later. We should indeed implement additional error handling. At least it's mostly reliable now, just took some work to make it stable.

Overall I've been rather disappointed with WCF, I've previously only used it for stateless processing and it's been fine. This time around, trying to achieve a reliable persistent connection, it's just been plain difficult to use. I've considered using CEF's native IPC mechanism, which is a possible, though requires more work than I have time for at the moment.

[amaitland]

@Bodekaer Merged your commit into JsBinding_Wip, thanks!

[atomaras]

Using the same logic in my own app that relies on NamedPipe IPC threw exceptions at runtime in 2 scenarios :

1. WCF did not like Send,Open,Close etc timeouts that are more that TimeSpan.FromMilliseconds(Int32.MaxValue)
2. WCF did not like an IdleTimeout of TimeSpan.MaxValue because an internal DateTime addition operation throws up.

I personally had to set TimeSpan.FromMilliseconds(Int32.MaxValue) i.e 24 days for all my timeouts.

Just as a heads up...

P.S @amaitland thanks SO much for the NamedPipe idle connection pooling link!

[amaitland]

@atomaras No problem. So from your experience you'd suggest changing from TimeSpan.MaxValue to TimeSpan.FromMilliseconds(Int32.MaxValue)?

@Bodekaer Any feedback on this? How's everything been running?

I'm happy to make a few tweaks if it increases the stability 😄