[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Christian Bauer updated HSEARCH-88: ----------------------------------- Priority: Minor (was: Blocker) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Charles Chappell updated HSEARCH-88: ------------------------------------ Attachment: Login.java I'll hopefully have a test case sometime today. I added this issue before I went to sleep last night, and am working on simplifying the issue today. The problem is at present that this involves: App Client -> Web Service -> EJB -> Hibernate Persistence/Search Basically I have a "login" function that checks to see if a user "admin" and other "initial" data exists. If no, it creates the data, and returns the newly created "admin" user to the calling web service, which then uses this in a further processing step to create a login session, and a stateful web service endpoint with an associated stateful EJB. (nice and simple huh?) In the process of doing this, 6 different entity beans are touched, including the offending "Login" bean. ------ Update ------ The NPE was actually being caused by the exception, and it's not *easily* reproducible in the login step. That seems to be a race condition between the updates from the initial insert, and grabbing data when the login process is proceeding. Frankly, I'm not sure how though, as I use the entity beans that I created during the initial data creation step in the following login steps. In any event, I was only able to produce that once, and the assertion failures I'm getting now are in different, but related functions. In all cases, it's centering around a single association of my main class though, so I'm posting the classes here for perusal. I am working on a test case for this, so this is informational at this point, but know that this class is always the one reported. It's entirely possible that I've misconfigured something in this class, but this is also the only class I use that has a @ContainedIn notation. I'll post the Person class that this links to as well. I keep getting assertion failures for EntityManager.find operations under GlassFish Build 41, using the previously noted versions of Hibernate. Here's a trace of the exception that I was able to get. (I did try to get it from within the EJB, but it doesn't show up, even if I do a try { entire function mentioned } catch (Throwable t) { t.printStackTrace(); } org.hibernate.annotations.common.AssertionFailure: Tries to read for update a index while a writer is accessedclass org.mc3.entity.party.Login at org.hibernate.search.backend.Workspace.getIndexReader(Workspace.java:54) at org.hibernate.search.backend.impl.lucene.LuceneWorker.remove(LuceneWorker.java:85) at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:73) at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:41) at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.run(LuceneBackendQueueProcessor.java:37) at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:131) at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.afterCompletion(PostTransactionWorkQueueSynchronization.java:50) at com.sun.enterprise.distributedtx.J2EETransaction.commit(J2EETransaction.java:491) at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:371) at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3781) at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3560) at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1373) at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1343) at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1305) at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205) at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:83) at $Proxy175.find(Unknown Source) at org.mc3.ccms.web.service.Session.find(Session.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:232) at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:132) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:241) at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:74) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400) at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:70) at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147) at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:79) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400) at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:70) at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218) at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129) at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:79) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559) The EJB Find function mentioned here is extremely simple: @PersistenceContext private EntityManager em; public Object find(Class klass, Object object) { return em.find(klass,object); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Charles Chappell updated HSEARCH-88: ------------------------------------ Attachment: testcase.tar.gz Test case is implemented as a single .war file. Requires appropriate drivers for PostGRE on the server side, uses a database connection to test:test@localhost/test by default. Creates only a couple of tables in the database. Run the test case, then look at the Application Server Log files. This produces an assertion failure for every commit after the first. If anyone needs a fresh pair of eyes looking at the Hibernate Search source, I'd be happy to lend mine for a bit, but please give me an idea of where to look. In this case, the important files are in the src/java/entity and src/java/servlets folders. Everything else is Netbeans 5.5.1 infrastructure. (Sorry for not mentioning until now... I'm using Netbeans 5.5.1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Charles Chappell commented on HSEARCH-88: ----------------------------------------- Last comment of the day for me (back to my main line of work): If you create a second Login class that has no Hibernate Search annotations, and search in the same way as above, it still causes assertion failures. This may give some clue into what's going on, as it seems like this issue is coming up during a find transaction that also fetches a Hibernate Search indexed entity. I'm not sure what the limits are of this yet, but the case I've supplied should be complete enough to play with this. If I figure out what's actually causing my application to fail, I'll add it to the test case. I'm pretty sure it's hibernate search though, as there were no problems in this section of code until I started annotating the Person and Login entities as Indexed. This test case is showing relatively harmless failures, as the data is still retrieved either way. In my EJB, the data isn't retrieved, causing failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Emmanuel Bernard resolved HSEARCH-88. ------------------------------------- Resolution: Fixed OK I found the issues, my hash based ordering algorithm was flawed when 2 entity types shared the same underlying index. It should be fixed now (in SVN) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Emmanuel Bernard commented on HSEARCH-88: ----------------------------------------- Thanks for the test cases, that helped! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-88?page... ] Emmanuel Bernard commented on HSEARCH-88: ----------------------------------------- Unit tests are definitely better, but it requires to somehow have isolated the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira