search

Red5 / red5-hls-plugin

HLS support as a plugin for Red5
Apache License 2.0
80 stars 51 forks source link

Interrupted Exception #2

Open kodjobaah opened 10 years ago

kodjobaah commented 10 years ago

When Playing a stream for about five minutes I get the following error... Replacing all RentrentLocks with synchronized on the method instead seems to have resolved the problem. Not too sure what impact this will have on performance...

2014-03-07 21:45:45,494 [SegmentExecutor-1] WARN o.r.s.httpstream.SegmentFacade - Exception trying lock java.lang.InterruptedException: null at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1244) ~[na:1.7.0_25] at java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:445) ~[na:1.7.0_25] at org.red5.service.httpstream.SegmentFacade.getSegment(SegmentFacade.java:317) ~[hls-plugin-1.1.jar:na] at org.red5.stream.http.xuggler.MpegTsIoHandler.write(MpegTsIoHandler.java:59) ~[hls-plugin-1.1.jar:na] at org.red5.stream.http.xuggler.MpegTsHandler.close(MpegTsHandler.java:101) ~[hls-plugin-1.1.jar:na] at com.xuggle.xuggler.XugglerJNI.IContainer_close(Native Method) ~[xuggle-xuggler-noarch.jar:5.5.0] at com.xuggle.xuggler.IContainer.close(IContainer.java:672) ~[xuggle-xuggler-noarch.jar:5.5.0] at org.red5.xuggler.writer.HLSStreamWriter.close(HLSStreamWriter.java:604) ~[hls-plugin-1.1.jar:na] at org.red5.service.httpstream.SegmentFacade$QueueWorker.run(SegmentFacade.java:644) ~[hls-plugin-1.1.jar:na] at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:53) ~[spring-context-3.1.4.RELEASE.jar:3.1.4.RELEASE] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_25] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) ~[na:1.7.0_25] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) ~[na:1.7.0_25]

mondain commented 10 years ago

I'm cool with finding an alternative fix here, other than using synchronized. I primarily use concurrent locks to support the multi-threaded nature of the server; throwing synchronized at every threading issue is like using Mjolnir to hammer a tack into a cork board. http://lycog.com/concurency/performance-reentrantlock-synchronized/ http://stackoverflow.com/questions/11821801/why-use-a-reentrantlock-if-one-can-use-synchronizedthis

kodjobaah commented 10 years ago

Thank you for the link..only reason why I went with the synchronized approach was that it was a quick fix to see if the exceptions would disappear..and also I just re-read brian goetz book..java concurrency in practice..where he gives use cases for when you should used a reentrantlock..chapter 13.4.

ReentrantLock is an advanced tool for situations where intrinsic locking is not practical. Use it if you need its advanced features: timed, polled, or interruptible lock acquisition, fair queuing, or non‐block‐structured locking. Otherwise, prefer synchronized.

But you are absolutely right..a non blocking strategy would be much better..