[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Ochieng Marembo (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Ochieng Marembo edited comment on WFLY-3386 at 3/28/15 4:58 PM:
----------------------------------------------------------------
These thread may be old, but i was getting the exact same scenario, and then figured out why.
I had a sessioninitialization listener, which was failing, on
{code:java}
HttpSessionListener.sessionCreated(HttpSessionEvent)
{code}
so when AbstractSessionBeanStore.getLockStore tries to get hold of a new session, an exception occurs, which seems to be ignored somewhere in the event call chain, and hence getSession(true) effectively returns null.
The best solution for this is to ensure that the Exception that occurs during session creation is propagated properly and should terminate with the initial cause.
was (Author: marembo2008):
These thread may be old, but i was getting the exact same scenario, and then figured out why.
I had a sessioninitialization listener, which was failing, on ```HttpSessionListener.sessionCreated(HttpSessionEvent)```
so when AbstractSessionBeanStore.getLockStore tries to get hold of a new session, an exception occurs, which seems to be ignored somewhere in the event call chain, and hence getSession(true) effectively returns null.
The best solution for this is to ensure that the Exception that occurs during session creation is propagated properly and should terminate with the initial cause.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Ochieng Marembo (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Ochieng Marembo commented on WFLY-3386:
---------------------------------------
These thread may be old, but i was getting the exact same scenario, and then figured out why.
I had a sessioninitialization listener, which was failing, on ```HttpSessionListener.sessionCreated(HttpSessionEvent)```
so when AbstractSessionBeanStore.getLockStore tries to get hold of a new session, an exception occurs, which seems to be ignored somewhere in the event call chain, and hence getSession(true) effectively returns null.
The best solution for this is to ensure that the Exception that occurs during session creation is propagated properly and should terminate with the initial cause.
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (WFLY-4169) Wildfly doesn't fail on deployment EJB with CDI @Transactional
by Eduardo Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-4169?page=com.atlassian.jira.plugin.... ]
Eduardo Silva commented on WFLY-4169:
-------------------------------------
In the ejb-3_2 specification :
It is illegal to associate JTA transactional interceptors (see [8]) with Enterprise JavaBeans. The EJB Container should fail deployment of such applications.[39]
@Transaction annotation was introduced in JTA 1.2,
As Narayana 5.0.0.M3 is now JTA 1.2 compliant, and it was introduced on Wildfly since version WildFly 8.0.0.Beta1
Because this restriction could be removed in the future versions:
[39] This restriction may be removed in a future release of this specification
> Wildfly doesn't fail on deployment EJB with CDI @Transactional
> --------------------------------------------------------------
>
> Key: WFLY-4169
> URL: https://issues.jboss.org/browse/WFLY-4169
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Kamil Żbikowski
>
> When javax.transaction.@Transactional CDI is put on EJB application is able to be correctly deployed on the server. According to JSR345 it should not be possible. ??It is illegal to associate JTA transactional interceptors \[8\] with Enterprise JavaBeans. The EJB Container should fail deployment of such applications.??
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called
by John Sanda (JIRA)
[ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.... ]
John Sanda reopened WFLY-3962:
------------------------------
I am reopening this since we are still seeing this with WildFly 8.2.0.Final. I will see if we can reproduce with 9.0.0.Beta1 early next week.
> onComplete for async listeners not always called
> ------------------------------------------------
>
> Key: WFLY-3962
> URL: https://issues.jboss.org/browse/WFLY-3962
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Heiko Rupp
> Assignee: Stuart Douglas
> Fix For: 8.2.0.Final, 9.0.0.Beta1
>
>
> I have a servlet filter that does
> chain.doFilter(requestWrapper, responseWrapper);
> if (request.isAsyncStarted()) {
> asyncListener = request.getAsyncContext().createListener(JsonPAsyncListener.class);
> request.getAsyncContext().addListener(asyncListener, requestWrapper, responseWrapper);
> }
> And (sometimes) this works well so that the onComplete() method of the listener is called.
> But this does not happen always. In some (repeatable) condition none of the callback methods in my AsyncListener are called.
> I was first thinking that the servlet (resteasy) behind chain.doFilter() is so fast that it completes
> before I can add the listener.
> But then I tried adding a Thread.sleep() in the RE code which did not change anything.
> Similar when I do a startAsync() and add the listener before calling chain.doFilter()
> This happens both on Wfly 8.0 and 8.1
> Basically it boils down that if the "backend" uses Futures.immediateFuture(result) , onComplete is not called.
> I have created a as small as possible war file + a read me on how to drive that via curl.
> See https://github.com/pilhuhn/misc/tree/master/web-goo
> I just added 2 examples to the readme file that show that if no
> wrapping by the filter is requested, the resteasy code works with
> both Futures.immediate... and Futures.transform(...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (JGRP-1921) Race condition in GroupRequest
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-1921?page=com.atlassian.jira.plugin.... ]
Dennis Reed closed JGRP-1921.
-----------------------------
Resolution: Won't Fix
Does not affect current versions of JGroups.
If a fix is needed for EAP 5.2, contact Red Hat support through the normal channels.
> Race condition in GroupRequest
> ------------------------------
>
> Key: JGRP-1921
> URL: https://issues.jboss.org/browse/JGRP-1921
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.6.23
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Priority: Minor
>
> Race condition in GroupRequest can make it wait for the full timeout even after all responses are received.
> GroupRequest.execute broadcasts the request, sets "done=false", then waits for a reply.
> If all the replies come in before it sets done=false, it will overwrite the done=true set by the responses and wait for the full timeout, and then return false.
> Note that the internal uses by MessageDispatcher/etc do not check the return value from execute, so this does not affect the data returned, only how long the call blocks for.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (JGRP-1921) Race condition in GroupRequest
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/JGRP-1921?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-1921:
-----------------------------------
Later versions (I checked 3.0.9) are not affected, as they do not set done=false in execute().
> Race condition in GroupRequest
> ------------------------------
>
> Key: JGRP-1921
> URL: https://issues.jboss.org/browse/JGRP-1921
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.6.23
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Priority: Minor
>
> Race condition in GroupRequest can make it wait for the full timeout even after all responses are received.
> GroupRequest.execute broadcasts the request, sets "done=false", then waits for a reply.
> If all the replies come in before it sets done=false, it will overwrite the done=true set by the responses and wait for the full timeout, and then return false.
> Note that the internal uses by MessageDispatcher/etc do not check the return value from execute, so this does not affect the data returned, only how long the call blocks for.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (JGRP-1921) Race condition in GroupRequest
by Dennis Reed (JIRA)
Dennis Reed created JGRP-1921:
---------------------------------
Summary: Race condition in GroupRequest
Key: JGRP-1921
URL: https://issues.jboss.org/browse/JGRP-1921
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.23
Reporter: Dennis Reed
Assignee: Dennis Reed
Priority: Minor
Race condition in GroupRequest can make it wait for the full timeout even after all responses are received.
GroupRequest.execute broadcasts the request, sets "done=false", then waits for a reply.
If all the replies come in before it sets done=false, it will overwrite the done=true set by the responses and wait for the full timeout, and then return false.
Note that the internal uses by MessageDispatcher/etc do not check the return value from execute, so this does not affect the data returned, only how long the call blocks for.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFCORE-616) Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-616:
---------------------------------------
Summary: Ensure end users cannot set the ""execute-for-coordinator" operation header via the HTTP interface
Key: WFCORE-616
URL: https://issues.jboss.org/browse/WFCORE-616
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Affects Versions: 1.0.0.Alpha19
Reporter: Brian Stansberry
The "execute-for-coordinator" header is used internally in domain-wide operation execution to indicate that a call is being made on behalf of the DC. End users should not be able to use it.
Client calls that go through the native handling (including HTTP upgrade) have any such header stripped by ModelControllerClientOperationHandler.ExecuteRequestHandler. We need to do the same thing in the domain-http code for non-upgrade HTTP calls.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called
by John Sanda (JIRA)
[ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.... ]
John Sanda commented on WFLY-3962:
----------------------------------
It looks like we are still seeing this in WildFly 8.2.0.Final. Our QE team created https://issues.jboss.org/browse/HWKMETRICS-47 and then I found this issue. It does not happen consistently with every test run, but it is somewhat frequent.
> onComplete for async listeners not always called
> ------------------------------------------------
>
> Key: WFLY-3962
> URL: https://issues.jboss.org/browse/WFLY-3962
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Heiko Rupp
> Assignee: Stuart Douglas
> Fix For: 8.2.0.Final, 9.0.0.Beta1
>
>
> I have a servlet filter that does
> chain.doFilter(requestWrapper, responseWrapper);
> if (request.isAsyncStarted()) {
> asyncListener = request.getAsyncContext().createListener(JsonPAsyncListener.class);
> request.getAsyncContext().addListener(asyncListener, requestWrapper, responseWrapper);
> }
> And (sometimes) this works well so that the onComplete() method of the listener is called.
> But this does not happen always. In some (repeatable) condition none of the callback methods in my AsyncListener are called.
> I was first thinking that the servlet (resteasy) behind chain.doFilter() is so fast that it completes
> before I can add the listener.
> But then I tried adding a Thread.sleep() in the RE code which did not change anything.
> Similar when I do a startAsync() and add the listener before calling chain.doFilter()
> This happens both on Wfly 8.0 and 8.1
> Basically it boils down that if the "backend" uses Futures.immediateFuture(result) , onComplete is not called.
> I have created a as small as possible war file + a read me on how to drive that via curl.
> See https://github.com/pilhuhn/misc/tree/master/web-goo
> I just added 2 examples to the readme file that show that if no
> wrapping by the filter is requested, the resteasy code works with
> both Futures.immediate... and Futures.transform(...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month