Interrupted Exception

[kodjobaah]

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]

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]

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..