mstein
commented
12 years ago Ah, this is a concurrency issue, the cleanOperationBatchList() method wasn't thread safe so that why you could have that issue in a multiple users scenario. Should be fixed with 072d220d08cd908d43481141ae5faf53a9602e7a
My Grails application gets frequent errors in IndexRequestQueue#cleanOperationBatchList() method.
Here is a typical stack trace:
Caused by: java.lang.NullPointerException at java.util.LinkedList.remove(LinkedList.java:791) at java.util.LinkedList.access$200(LinkedList.java:74) at java.util.LinkedList$ListItr.remove(LinkedList.java:732) at org.grails.plugins.elasticsearch.index.IndexRequestQueue.cleanOperationBatchList(IndexRequestQueue.java:245) at org.grails.plugins.elasticsearch.index.IndexRequestQueue.executeRequests(IndexRequestQueue.java:143) at org.grails.plugins.elasticsearch.index.IndexRequestQueue$executeRequests.call(Unknown Source) at org.grails.plugins.elasticsearch.AuditEventListener.onFlush(AuditEventListener.groovy:178) at marketplace.ThemeService$$EnhancerByCGLIB$$a9441174.getCurrentTheme()
at marketplace.ThemeService$getCurrentTheme.call(Unknown Source)
Sometimes the NPE happens on line (current is null)
In the stack trace above the onFlush() method is invoked by an invocation of ThemeService.getCurrentTheme() method, which is marked as transactional, but should not be. Can this be causing the NPE? Is there an issue with transactional methods not doing any database writes as far as the Elastic Search is concerned?
Why would "current" variable defined as "it.next()" have null value (it happens rather frequently in our JMeter tests, especially when the number of user is significant). It does not happen in a one-user scenarios.