From BENJAMIC at uk.ibm.com Sun Oct 2 05:36:36 2016 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Sun, 2 Oct 2016 10:36:36 +0100 Subject: [weld-dev] Race condition in HttpContextLifecycle requestInitialized Message-ID: Hello. We have a problem from a race condition in HttpContextLifecycle.requestInitialized() The condition is as follows: Thread one calls nestedInvocationGuard.set(new Counter()); Thread two calls Counter counter = nestedInvocationGuard.get(); Object marker = request.getAttribute(GUARD_PARAMETER_NAME); Thread one has not yet called request.setAttribute(GUARD_PARAMETER_NAME, GUARD_PARAMETER_VALUE); This will result in thread two having a counter but no marker, leading to ServletLogger.LOG.guardLeak(counter.value); I believe this issue is known because of the following comment. * This request has not been processed yet but the guard is set already. That indicates, that the guard leaked from a previous request * processing - most likely the Servlet container did not invoke listener methods symmetrically. Log a warning and recover by * re-initializing the guard I am assuming that "symmetrically" is supposed to say "synchronised". I have checked with the relevant team and there is no way we can call that method from inside a synchronised block. So I was hoping that you might have some alternatives? I noticed that the file at https://github.com/doctau/weld-core/blob/master/impl/src/main/java/org/jboss/weld/servlet/HttpContextLifecycle.java has been updated and no longer has that race condition? Do you think including that update resolve this issue? And if so which release will include that update. Regards Benjamin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161002/bccc2587/attachment.html From mkouba at redhat.com Mon Oct 3 02:56:15 2016 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 3 Oct 2016 08:56:15 +0200 Subject: [weld-dev] Race condition in HttpContextLifecycle requestInitialized In-Reply-To: References: Message-ID: <89a340f2-167c-8ac9-78a9-2c3e61dd7136@redhat.com> Hi Benjamin, Dne 2.10.2016 v 11:36 Benjamin Confino napsal(a): > Hello. > > We have a problem from a race condition in > HttpContextLifecycle.requestInitialized() > > The condition is as follows: > > Thread one calls nestedInvocationGuard.set(*new*Counter()); > Thread two calls Counter counter = nestedInvocationGuard.get(); Object > marker = request.getAttribute(GUARD_PARAMETER_NAME); > Thread one has not yet called request.setAttribute(GUARD_PARAMETER_NAME, > GUARD_PARAMETER_VALUE); I don't understand how this could be a race condition? Are you saying that both these threads are processing a single request at the same time? > > This will result in thread two having a counter but no marker, leading > to ServletLogger.LOG.guardLeak(counter.value); > > I believe this issue is known because of the following comment. > > * This request has not been processed yet but the guard is set already. > That indicates, that the guard leaked from a previous request > * processing - most likely the Servlet container did not invoke listener > methods symmetrically. Log a warning and recover by > * re-initializing the guard > > I am assuming that "symmetrically" is supposed to say "synchronised". No it's not. It is really supposed to say symmetrically, it means that ServletRequestListener.requestInitialized(ServletRequestEvent) should be always followed by ServletRequestListener.requestDestroyed(ServletRequestEvent)? > > I have checked with the relevant team and there is no way we can call > that method from inside a synchronised block. So I was hoping that you > might have some alternatives? > > I noticed that the file at > https://github.com/doctau/weld-core/blob/master/impl/src/main/java/org/jboss/weld/servlet/HttpContextLifecycle.javahas > been updated and no longer has that race condition? Do you think > including that update resolve this issue? And if so which release will > include that update. What version of Weld are you using? What "update" do you have in mind? > > Regards > Benjamin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Software Engineer Red Hat, Czech Republic From BENJAMIC at uk.ibm.com Thu Oct 20 12:22:31 2016 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Thu, 20 Oct 2016 17:22:31 +0100 Subject: [weld-dev] Unique BeanIdentifierIndex every time I restart a server Message-ID: Hello. I've been investigating a bug relating to session failover and I've noticed that my BeanIdentifierIndex has a different hash every time I start and stop the server. This is consistent across every app I tried. For example: Upon starting the server I see my debug output GREP BeanIdentifierIndex [hash=591986009, indexed=3] 0: WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession 1: WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession 2: WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader at d6318459[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession I stop the server, and start it again GREP BeanIdentifierIndex [hash=-375657379, indexed=3] 0: WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession 1: WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession 2: WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader at b3a3f568[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession Same three classes but the hash is completely different. My question is simple. Is this the expected behaviour or is this a sign that something's gone wrong? Regards Benjamin Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161020/038d781b/attachment-0001.html From mkouba at redhat.com Fri Oct 21 03:33:31 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 21 Oct 2016 09:33:31 +0200 Subject: [weld-dev] Unique BeanIdentifierIndex every time I restart a server In-Reply-To: References: Message-ID: <6717a739-77ca-2521-90e2-eeaf2aebd214@redhat.com> Hi Benjamin, it looks like an integration issue. The index hash should be the same unless an ID of a session/conversation scoped bean changes. Its value is computed using java.util.Arrays.hashCode(BeanIdentifier[]). Note that BeanIdentifier.hashCode() is always based on the String representation of the ID. In you case, I can see the difference in: org.eclipse.osgi.internal.loader.EquinoxClassLoader at d6318459 org.eclipse.osgi.internal.loader.EquinoxClassLoader at b3a3f568 It seems the BeanDeploymentArchive.getId() is different between deployments which violates the Weld SPI contract: "The identifier must be consistent between multiple occurrences of this deployment." [1] It's also possible to disable this optimization: http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#_bean_identifier_index_optimization Martin [1] https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/bootstrap/spi/BeanDeploymentArchive.java Dne 20.10.2016 v 18:22 Benjamin Confino napsal(a): > Hello. > > I've been investigating a bug relating to session failover and I've > noticed that my BeanIdentifierIndexhas a different hash every time I > start and stop the server. This is consistent across every app I tried. > > For example: > > Upon starting the server I see my debug output > > GREP BeanIdentifierIndex [hash=591986009, indexed=3] > 0: > WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession > > 1: > WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession > 2: > WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader at d6318459[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession > > > I stop the server, and start it again > > GREP BeanIdentifierIndex [hash=-375657379, indexed=3] > 0: > WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession > > 1: > WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession > 2: > WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader at b3a3f568[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession > > > Same three classes but the hash is completely different. > > My question is simple. Is this the expected behaviour or is this a sign > that something's gone wrong? > > Regards > Benjamin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Software Engineer Red Hat, Czech Republic From BENJAMIC at uk.ibm.com Fri Oct 21 11:55:06 2016 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Fri, 21 Oct 2016 16:55:06 +0100 Subject: [weld-dev] Unique BeanIdentifierIndex every time I restart a server In-Reply-To: <6717a739-77ca-2521-90e2-eeaf2aebd214@redhat.com> References: <6717a739-77ca-2521-90e2-eeaf2aebd214@redhat.com> Message-ID: Thanks Martin. It looks like I have an integration defect to track down. Regards Benjamin From: Martin Kouba To: Benjamin Confino/UK/IBM at IBMGB, weld-dev at lists.jboss.org, Cc: Emily Jiang/UK/IBM at IBMGB, Steven Schader Date: 21/10/2016 08:33 Subject: Re: [weld-dev] Unique BeanIdentifierIndex every time I restart a server Hi Benjamin, it looks like an integration issue. The index hash should be the same unless an ID of a session/conversation scoped bean changes. Its value is computed using java.util.Arrays.hashCode(BeanIdentifier[]). Note that BeanIdentifier.hashCode() is always based on the String representation of the ID. In you case, I can see the difference in: org.eclipse.osgi.internal.loader.EquinoxClassLoader at d6318459 org.eclipse.osgi.internal.loader.EquinoxClassLoader at b3a3f568 It seems the BeanDeploymentArchive.getId() is different between deployments which violates the Weld SPI contract: "The identifier must be consistent between multiple occurrences of this deployment." [1] It's also possible to disable this optimization: http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#_bean_identifier_index_optimization Martin [1] https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/bootstrap/spi/BeanDeploymentArchive.java Dne 20.10.2016 v 18:22 Benjamin Confino napsal(a): > Hello. > > I've been investigating a bug relating to session failover and I've > noticed that my BeanIdentifierIndexhas a different hash every time I > start and stop the server. This is consistent across every app I tried. > > For example: > > Upon starting the server I see my debug output > > GREP BeanIdentifierIndex [hash=591986009, indexed=3] > 0: > WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession > > 1: > WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession > 2: > WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader at d6318459[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession > > > I stop the server, and start it again > > GREP BeanIdentifierIndex [hash=-375657379, indexed=3] > 0: > WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession > > 1: > WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession > 2: > WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader at b3a3f568[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession > > > Same three classes but the hash is completely different. > > My question is simple. Is this the expected behaviour or is this a sign > that something's gone wrong? > > Regards > Benjamin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Software Engineer Red Hat, Czech Republic Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20161021/abb91b37/attachment.html