search

jgauffin / Griffin.Framework

Application framework for Business Applications
http://griffinframework.net
168 stars 62 forks source link

Unhandled SemaphoreFullException in TcpChannel OnSendCompleted #68

Open PhonicUK opened 8 years ago

PhonicUK commented 8 years ago

Adding the specified count to the semaphore would cause it to exceed its maximum count.

at System.Threading.SemaphoreSlim.Release (Int32 releaseCount) in <filename unknown="">:line 0
at System.Threading.SemaphoreSlim.Release () in <filename unknown="">:line 0
at Griffin.Net.Channels.TcpChannel.OnSendCompleted (System.Object sender, System.Net.Sockets.SocketAsyncEventArgs e) in <filename unknown="">:line 0
at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted (System.Net.Sockets.SocketAsyncEventArgs e) in <filename unknown="">:line 0
at System.Net.Sockets.SocketAsyncEventArgs.SendCallback (IAsyncResult ares) in <filename unknown="">:line 0
at System.Net.Sockets.SocketAsyncEventArgs.DispatcherCB (IAsyncResult ares) in <filename unknown="">:line 0
at System.Net.Sockets.SocketAsyncResult.<executeworkitem>m__1 (System.Object state) in <filename unknown="">:line 0
at (wrapper managed-to-native) System.Runtime.Remoting.Messaging.AsyncResult:Invoke (System.Runtime.Remoting.Messaging.AsyncResult)
at System.Runtime.Remoting.Messaging.AsyncResult.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () in <filename unknown="">:line 0
at System.Threading.ThreadPoolWorkQueue.Dispatch () in <filename unknown="">:line 0
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () in <filename unknown="">:line 0
SamKr commented 5 years ago

I'm having the same issue. Any idea/hints?

crash

SamKr commented 5 years ago

It seems there's a pull request fixing this issue, but it's quite old. Can you comment on whether it's safe to implement in the current build?

SamKr commented 5 years ago

It seems there's a pull request fixing this issue, but it's quite old. Can you comment on whether it's safe to implement in the current build?

Please ignore my reports, fault was on my side, client wasn't correctly closing connections.

fabianoriccardi commented 4 years ago

Any news on this topic? I'm getting the same problem while testing my small webserver with JMeter.

Please ignore my reports, fault was on my side, client wasn't correctly closing connections.

Is it possible that jMeter doesn't properly close the connection?

SamKr commented 4 years ago

Is it possible that jMeter doesn't properly close the connection?

Probably, perhaps these can help:

StackExchange Docs

Otherwise, your own webserver might be keeping them open?

fabianoriccardi commented 4 years ago

Thanks for the hint! Unfortunately, I'm testing HTTP protocol (HTTP Sampler) and it doesn't provide the reuse-connection checkbox...

Am I missing some "hidden" option?

fabianoriccardi commented 4 years ago

I've tested with Postman (single thread, postman doesn't allow multiple threads to send requests) and the server doesn't crash. I've tested with jMeter (force single user) and it rarely crashes. Moreover, per each request, an exception is generated, while in Postman the server works seamlessly.

However, a server shouldn't crash if requests aren't well-formed.