We are seeing such error message in our server log constantly; does anyone know what might be? Thanks.
2009-01-30 08:59:12 EST (Framework : FATAL) - [POP.001.0002] A “java.lang.NullPointerException” occurred with the Message “at com.webMethods.portal.service.task.impl.TaskThing.setLastUpdatedByValue(TaskThing.java:283)”
java.lang.NullPointerException
at com.webMethods.portal.service.task.impl.TaskThing.setLastUpdatedByValue(TaskThing.java:283)
at com.webMethods.portal.service.task.impl.TaskService.updateTask(TaskService.java:131)
at com.webMethods.portal.mech.task.impl.TaskMechanics.addProcessedRules(TaskMechanics.java:1788)
at com.webMethods.portal.mech.task.impl.TaskScheduleHandler.onEvent(TaskScheduleHandler.java:175)
at com.webMethods.portal.service.meta2.system.IScheduleEvent$Listeners$Listener.onEvent(IScheduleEvent.java:32)
at com.webMethods.rtl.event.BaseListeners$ObjectEvListener.onEvent(BaseListeners.java:71)
at com.webMethods.rtl.event.QueueDeliverer$EventQueue.onMessage(QueueDeliverer.java:417)
at com.webMethods.rtl.msg.ListenerProxy.onMessage(ListenerProxy.java:90)
at com.webMethods.rtl.msg.jms.JMSDestination$Subscriber.onMessage(JMSDestination.java:249)
at com.webMethods.jms.db.impl.JMSDispatcherThread.run(JMSDispatcherThread.java:107)
2009-01-30 08:59:12 EST (Framework : FATAL) - [POP.001.0002] A “java.lang.NullPointerException” occurred with the
Looks like it could be a problem with the data received on a message which is resulting in the error. It is a little difficult to be precise so I’m guessing based on the stack trace that you’ve a message coming on a JMS queue (possibly the PE JMS connection) and this is being passed to a service that is invoking (something to do with) a workflow task. Given that it is a null pointer exception that might indicate either data missing on the actual message, or the data is incorrect so that subsequent lookups result in data missing.
I’d have a look at the queue associated with the Process Engine on Broker to see if there are trapped messages on there (use Broker Administrator to browse the queue - be careful on production systems if you need to lock the queue) - you may see the message being retried repeatedly by the JMS dispatcher which would explain the repeated error. To check the context of what is consuming the message you would need to look at the JMS triggers on your IS to locate a subscription to the relevant document type (in Developer, try checking dependents for the document type you find on the Broker to locate relevant triggers).
Resolution might be to extract the message off the queue in the administration screens, get the contents for diagnosis and then acknowledge (delete it). Again, exercise appropriate caution on a live system.