Service invocation error causing "due to long handshake" errors?

[Eilon Yardeni]

Hi,

We are using red5 1.0rc1. We have found an issue were some calls from the clients
were failing with "Service invocation error" due to an uncaught exception on the server.

This seems legitimate as the client still knows the method call failed.

But what seems to be strange is that after a few hundred of "Service invocation errors" in about 5-10 minutes, we started seeing new connections failing with "due to long handshake" errors (handshake timeout is at 10 seconds).

Next we started seeing existing connections been closed with "due to too much inactivity" error.

Are these connected? why would service invocation errors cause such an effect?

Thanks,
Eilon

[Mondain]

In that version, the invocation errors did seem to lead to loosing the ability to connect additional connections after a given period of time.

--
 
---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to red5interest...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
http://gregoire.org/
http://code.google.com/p/red5/

[Eilon Yardeni]

Thanks for the prompt response!

Is this fixed in 1.0? Can you point me to the buggy part? I may be able to merge the fix into the 1.0rc1 that we use.

Eilon

[Mondain]

I believe it is fixed, yes. You'll want to look at the ServiceInvoker class.

[Eilon Yardeni]

Hmm.. ServiceInvoker from 1.0rc1 looks pretty much the same as in trunk

[hoops]

are you using SSL ? (rtmps) ? 

[Eilon Yardeni]

No..

--

[hoops]

we were seeing something similar on rtmps - basically the thread pool for the executors where being starved, due to threads deadlocking on invoke - it seeked the semaphore for writeRaw was the issue (as it was not reentrant).  Replaced with lock - ie. something to do with SSL for mina, recursively calling back into the RTMPMinaConnection on the same thread (which the semaphore doesn't like).

[Thomas Auge]

On Saturday, April 27, 2013 11:05:00 PM UTC-4, hoops wrote:

we were seeing something similar on rtmps - basically the thread pool for the executors where being starved, due to threads deadlocking on invoke - it seeked the semaphore for writeRaw was the issue (as it was not reentrant).  Replaced with lock - ie. something to do with SSL for mina, recursively calling back into the RTMPMinaConnection on the same thread (which the semaphore doesn't like).

 Since I currently have the same problem with RTMPS, could you translate your solution for someone clueless please? :-)