I am trying to get the Handviewer java sample project running. When running the application crashes after (1-2 sec) and firing the following exceptions!
Please note that I have managed to run the UserViewers.java sample without problems. and I am running on OSX 10.8.3, NiTE-MacOSX-x64-2.2, OpenNI-MacOSX-x64-2.2, and Asus XtionPro Live.
Exception in thread "Thread-17" java.util.NoSuchElementException: Unknown pixel format: 0
at org.openni.PixelFormat.fromNative(PixelFormat.java:30)
at org.openni.VideoMode.<init>(VideoMode.java:38)
at com.primesense.nite.NativeMethods.niteReadHandTrackerFrame(Native Method)
at com.primesense.nite.HandTracker.readFrame(HandTracker.java:139)
at com.primesense.nite.Samples.HandViewer.HandViewer.onNewFrame(HandViewer.java:69)
at com.primesense.nite.HandTracker.onFrameReady(HandTracker.java:360)
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at com.primesense.nite.Samples.HandViewer.HandViewer.paint(HandViewer.java:55)
at javax.swing.JComponent.paintChildren(JComponent.java:884)
at javax.swing.JComponent.paint(JComponent.java:1046)
at javax.swing.JComponent._paintImmediately(JComponent.java:5106)
at javax.swing.JComponent.paintImmediately(JComponent.java:4890)
at javax.swing.RepaintManager$3.run(RepaintManager.java:814)
at javax.swing.RepaintManager$3.run(RepaintManager.java:802)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:802)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:745)
at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:725)
at javax.swing.RepaintManager.access$1000(RepaintManager.java:46)
at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1684)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:708)
at java.awt.EventQueue.access$400(EventQueue.java:82)
at java.awt.EventQueue$2.run(EventQueue.java:669)
at java.awt.EventQueue$2.run(EventQueue.java:667)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:678)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
This probably won't help you much because it's already been a while... but I have had a similar problem with my Kinect. I could resolve everything by reinstalling everything and switching to OpenNI 1.5.4. Everything worked after that. Good luck.
Related
Good day everyone.
We have wso2 implemented on three Docker containers. Everything worked fine until after adding the next flow, the entrance to the Micro Integration Dashboard stopped working. Moreover, the system itself continues to work, only you can not enter the panel.
Error image
login failed internal server error
No changes were made to the users or to the container itself.
I've searched and read everything I can, but I can't even grasp where the problem is.
Please push me in the right direction.
Here is the error from the logs:
[2023-01-12 07:40:08,602] ERROR {LoginDelegate} - Error logging into dashboard server java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:459)
at org.wso2.ei.dashboard.core.rest.delegates.auth.LoginDelegate.getTokenFromMI(LoginDelegate.java:80)
at org.wso2.ei.dashboard.core.rest.delegates.auth.LoginDelegate.authenticateUser(LoginDelegate.java:51)
at org.wso2.ei.dashboard.core.rest.api.LoginApi.receiveLogin(LoginApi.java:56)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:76)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:148)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:191)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:200)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:103)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:493)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:415)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:104)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:277)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:272)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:268)
at org.glassfish.jersey.internal.Errors.process(Errors.java:316)
at org.glassfish.jersey.internal.Errors.process(Errors.java:298)
at org.glassfish.jersey.internal.Errors.process(Errors.java:268)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:289)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:256)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:416)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:389)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:342)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:229)
at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1450)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:600)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1440)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410)
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
at java.base/java.lang.Thread.run(Thread.java:829)
My application is designed in such a way that whenever someone tries to start it, the application will close other instances of itself. (notice that this is working as expected and should not be changed).
I am using Akka and one of my Actors is a PersistentActor that uses leveldb.
When the application starts it locks <path-to-lock>/LOCK, when it starts again the leveldb cannot lock the file so the PersistentActor cannot start.
After some inspection I found that the leveldb Actor class is LeveldbJournal and it starts under the system guardian with path akka://actor-system/system/akka.persistence.journal.leveldb.
I would like leveldb to restart itself until the file can be locked or a max retries limit has reached.
Logs:
[ERROR] [02/04/2019 15:39:25.731] [operator-actor-system-akka.actor.default-dispatcher-5] [akka://operator-actor-system/system/akka.persistence.journal.leveldb] Unable to acquire lock on '<path-to-lock>/LOCK'
akka.actor.ActorInitializationException: akka://operator-actor-system/system/akka.persistence.journal.leveldb: exception during creation
at akka.actor.ActorInitializationException$.apply(Actor.scala:180)
at akka.actor.ActorCell.create(ActorCell.scala:607)
at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:461)
at akka.actor.ActorCell.systemInvoke(ActorCell.scala:483)
at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:282)
at akka.dispatch.Mailbox.run(Mailbox.scala:223)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Unable to acquire lock on '<path-to-lock>/LOCK'
at org.iq80.leveldb.impl.DbLock.<init>(DbLock.java:55)
at org.iq80.leveldb.impl.DbImpl.<init>(DbImpl.java:167)
at org.iq80.leveldb.impl.Iq80DBFactory.open(Iq80DBFactory.java:59)
at akka.persistence.journal.leveldb.LeveldbStore$class.preStart(LeveldbStore.scala:178)
at akka.persistence.journal.leveldb.LeveldbJournal.preStart(LeveldbJournal.scala:23)
at akka.actor.Actor$class.aroundPreStart(Actor.scala:510)
at akka.persistence.journal.leveldb.LeveldbJournal.aroundPreStart(LeveldbJournal.scala:23)
at akka.actor.ActorCell.create(ActorCell.scala:590)
... 7 more
When the PersistentActor restarts:
[ERROR] [02/04/2019 15:39:57.168] [operator-actor-system-akka.actor.default-dispatcher-16] [akka://operator-actor-system/user/controller/view-manager/records-service-api-supervisor/records-service-api] Persistence failure when replaying events for persistenceId [record-service-persistence-actor]. Last known sequence number [0] (akka.persistence.RecoveryTimedOut)
Thanks,
Ido Sorozon
P.S. Versions:
Scala: 2.11.8
Akka: 2.4.19
In my application i use infinispan as distributed cache.
I work with 3 application server running: wildfly 9.2. On each of them i job is exectuted and its work is just to validate some cache items. If the validation fails the job will remove the cache as it's not valid any more.
The removing code is quite simple:
if (somecondition){
cacheManager.removeCache(sessionCacheName);
}
I realized that when all three server are running (so there are 3 jobs that concurrently execute the romove operation) i get systematically this exception:
19:43:00,005 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-20,ws-7-aor-57542) ISPN000220: Problems un-marshalling remote command from byte buffer
a.lang.NullPointerException
at org.infinispan.commands.RemoteCommandsFactory.fromStream(RemoteCommandsFactory.java:219)
at org.infinispan.marshall.exts.ReplicableCommandExternalizer.fromStream(ReplicableCommandExternalizer.java:107)
at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:155)
at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:65)
at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:436)
at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:227)
at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:153)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:134)
at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:298)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:675)
at org.jgroups.JChannel.up(JChannel.java:739)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:383)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1042)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:435)
at org.jgroups.protocols.pbcast.NAKACK2.deliver(NAKACK2.java:961)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:843)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:291)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1796)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
on one server while this one:
19:44:00,199 ERROR [stderr] (DefaultQuartzScheduler_Worker-1) Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ws-7-aor-36158, see cause for remote stack trace
19:44:00,200 ERROR [stderr] (DefaultQuartzScheduler_Worker-1) at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46)
19:44:00,211 ERROR [stderr] (DefaultQuartzScheduler_Worker-1) at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:71)
19:44:00,211 ERROR [stderr] (DefaultQuartzScheduler_Worker-1) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:586)
19:44:00,212 ERROR [stderr] (DefaultQuartzScheduler_Worker-1) at org.infinispan.manager.DefaultCacheManager.removeCache(DefaultCacheManager.java:492)
on the other 2.
This error disappear when there is only 1 application server instance running.
So it's clearly related to the concurrence.
What am i missing?
The removeCache() method was only intended as an admin operation to be called from a JMX/RHQ console, so concurrent calls weren't much of a concern.
The good news is that concurrent calls will work in Infinispan 8.1+/WildFly 10, which include the fix for ISPN-5756.
I am trying to run one my process through callgrind. One of the child process (that I need to trace) calls into libhdfs and when running through callgrind this throws an exception:
java.util.ServiceConfigurationError: org.apache.hadoop.fs.FileSystem: Provider org.apache.hadoop.fs.viewfs.ViewFileSystem could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:224)
at java.util.ServiceLoader.access$100(ServiceLoader.java:181)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at org.apache.hadoop.fs.FileSystem.loadFileSystems(FileSystem.java:2602)
Caused by: java.lang.ExceptionInInitializerError
at org.apache.hadoop.fs.viewfs.ViewFileSystem.<init>(ViewFileSystem.java:134)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
... 2 more
Caused by: java.lang.IllegalArgumentException: java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file com/sun/proxy/$Proxy7
at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:685)
at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:592)
at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:244)
at java.lang.reflect.WeakCache.get(WeakCache.java:141)
at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:455)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:738)
at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.getProxyForCallback(MetricsSystemImpl.java:315)
at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:311)
at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.register(MetricsSystemImpl.java:237)
at org.apache.hadoop.metrics2.MetricsSystem.register(MetricsSystem.java:60)
at org.apache.hadoop.security.UserGroupInformation$UgiMetrics.create(UserGroupInformation.java:120)
at org.apache.hadoop.security.UserGroupInformation.<clinit>(UserGroupInformation.java:236)
... 9 more
When running normally I do not get this exception. Any idea what's going on? I am new to valgrind/callgrind.
It appears that this is an issue with JVM which generates a lot of SIGSEGVs during it's normal course of operation which valgrind doesn't like. I overcame that with the following parameter to callgrind --vex-iropt-register-updates=allregs-at-mem-access.
I'm running Wowza 3.6.2 on Windows 8.1 (64 bit) and have enabled the Transcoder add-on. I'm using the transcoder to take JPEG-snapshots from the live stream. I've built a custom HTTPProvider, similar to what is described here. This works fine and I can get JPG-snapshots from the stream through my HTTPProvider.
The problem is that since I enabled the transcoder I get irritating error messages in my server log on onPublish and onUnPublish of any stream.
As a transcoder template I used the default transrate.xml that comes with the Wowza installation, without any modifications made to it.
When i publish to a stream asdf I get errors similar to this:
ERROR server comment - TranscoderSessionDestination.init[livereceiver/_definst_/asdf]: [asdf_160p]:java.lang.ArrayIndexOutOfBoundsException: 1
java.lang.ArrayIndexOutOfBoundsException: 1
at com.foo.wms.module.IncomingStreamEventHandler.getQueryStringMap(IncomingStreamEventHandler.java:191)
at com.foo.wms.module.IncomingStreamEventHandler.onPublish(IncomingStreamEventHandler.java:83)
at com.wowza.wms.stream.MediaStream.notifyActionPublish(Unknown Source)
at com.wowza.wms.stream.publish.Publisher.publish(Unknown Source)
at com.wowza.wms.stream.publish.Publisher.publish(Unknown Source)
at com.wowza.wms.transcoder.model.TranscoderSessionDestination.init(Unknown Source)
at com.wowza.wms.transcoder.model.TranscoderSession.a(Unknown Source)
at com.wowza.wms.transcoder.model.TranscoderSession.handleOnMetadata(Unknown Source)
at com.wowza.wms.transcoder.model.LiveStreamTranscoder.handleOnMetadata(Unknown Source)
at com.wowza.wms.stream.live.LiveStreamTranscoderRunner.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
And when I unpublish the stream I get this:
ERROR server comment - TranscoderSessionDestination.shutdown: [asdf_160p]:java.lang.NullPointerException
java.lang.NullPointerException
at com.foo.wms.module.IncomingStreamEventHandler.onUnPublish(IncomingStreamEventHandler.java:166)
at com.wowza.wms.stream.MediaStream.notifyActionUnPublish(Unknown Source)
at com.wowza.wms.stream.publish.Publisher.publish(Unknown Source)
at com.wowza.wms.stream.publish.Publisher.unpublish(Unknown Source)
at com.wowza.wms.transcoder.model.TranscoderSessionDestination.shutdown(Unknown Source)
at com.wowza.wms.transcoder.model.TranscoderSession.c(Unknown Source)
at com.wowza.wms.transcoder.model.TranscoderSession.shutdown(Unknown Source)
at com.wowza.wms.transcoder.model.LiveStreamTranscoder.shutdown(Unknown Source)
at com.wowza.wms.stream.live.LiveStreamTranscoderRunner.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
I get three of each exception when I publish/unpublish (one for each Encode block that is enabled in the transrate.xml file).
Does anyone have an idea on what might be causing this?
Here is a better way to determine if the stream is a transcoded stream and not a source stream
if(stream.isTranscodeResult()) return;
After posting my question I had another look at the stacktrace and realized what the problem was - I had been looking in the wrong direction the whole time. Since the problem appeared when I enabled the transcoder, I concluded that's where the problem must be. What I didn't realize was that onPublish and onUnPublish fires multiple times when you use the transcoder - one time for the incoming stream, and one time for every transcoded stream.
Within the onPublish and onUnPublish methods of my module I do stuff, like read querystring-paramters, which are not present on the transcoded streams. That is why the exceptions are thrown when the onPublish and onUnPublish methods are called for the transcoded streams.
To remedy this, I added two lines at the beginning of onPublish and onUnPublish methods.
if (streamName.contains("_"))
return;
A somewhat ugly solution, but I am in control of all stream names and do not allow underscore in them anyway, so in my case this works fine.
Update:
#flux has provided a much nicer solution for how to check if the stream is the result of a transcode operation. See his answer for more info.