[JBoss JIRA] (WFLY-4234) EjbSuspendInterceptor doesn't play well with undeploy
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4234?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4234.
----------------------------------
Fix Version/s: 9.0.0.CR1
Resolution: Done
> EjbSuspendInterceptor doesn't play well with undeploy
> ------------------------------------------------------
>
> Key: WFLY-4234
> URL: https://issues.jboss.org/browse/WFLY-4234
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Stuart Douglas
> Fix For: 9.0.0.CR1
>
>
> The scenario is performing undeployment of an EJB application in the presence of incoming requests.
> If my understanding of the suspend/resume mechanism is correct, in the ideal case, performing an undeployment should disable invocations arriving after undeployment has been initiated, and also allow requests active at undeployment initiation some time to complete.
> In the clustering integration test RemoteFailoverTestCase, I am seeing failures in which the foloowing sequence of events occurs:
> - an EJB invocation on EJB SFSB X gets past the EJBSuspendInterceptor
> - undeployment is initiated and suspend is called on the ControlPoint for X
> - undeployment proceeds, removing certain resources required for the invocation
> - the active invocation fails due to resources not being available
> Here is one such example (I have added some of my own tracing to identify ControlPoint activities.).
> This is a log from the test in which invocations are arriving from an EJB client during undeployment. The request with input value 2 starts and at about the same time, undeployment is called. The invocation gets past the interceptor but never gets a chance to finish.
> {code}
> [0m14:22:04,459 INFO [org.jboss.ejb.client] (main) JBoss EJB Client version 2.0.1.Final
> 14:22:04,485 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-5) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 14:22:04,492 INFO [org.jboss.ejb.client.remoting] (main) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@2ba6ac4c, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)4b79c7f7,channel=jboss.ejb,nodename=node-0]} on channel Channel ID ad5ee733 (outbound) of Remoting connection 29cd434b to /127.0.0.1:8080
> 14:22:04,500 INFO [stdout] (EJB default - 1) ControlPoint: beginRequest called
> 14:22:04,529 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-15) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 14:22:04,530 INFO [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-3-thread-2) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@2ba6ac4c, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection(a)74f6ab8a,channel=jboss.ejb,nodename=node-1]} on channel Channel ID d24c9830 (outbound) of Remoting connection 759d3b52 to /127.0.0.1:8180
> 14:22:04,542 INFO [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 2.0.1.Final
> 14:22:04,560 INFO [stdout] (EJB default - 1) ControlPoint: requestComplete called
> 14:22:09,682 INFO [stdout] (EJB default - 2) ControlPoint: beginRequest called
> 14:22:09,702 INFO [stdout] (EJB default - 2) ControlPoint: requestComplete called
> CLIENT: making invocation on bean: value = 1
> 14:22:09,710 INFO [stdout] (EJB default - 3) ControlPoint: beginRequest called
> 14:22:09,715 INFO [stdout] (EJB default - 3) ControlPoint: requestComplete called
> CLIENT: made invocation on bean [ node-0 ]: new value = 2
> 14:22:09,717 INFO [org.jboss.as.test.clustering.NodeUtil] (main) Undeploying deployment=deployment-0
> CLIENT: making invocation on bean: value = 2
> 14:22:09,728 INFO [stdout] (EJB default - 4) ControlPoint: beginRequest called
> 14:22:09,730 INFO [stdout] (ServerService Thread Pool -- 29) EJBComponent: stopping remote-failover-test:remote-failover-test:SlowToDestroyStatefulIncrementorBean
> 14:22:09,730 INFO [stdout] (ServerService Thread Pool -- 31) EJBComponent: stopping remote-failover-test:remote-failover-test:StatefulIncrementorBean
> 14:22:09,730 INFO [stdout] (ServerService Thread Pool -- 67) EJBComponent: stopping remote-failover-test:remote-failover-test:SecureStatelessIncrementorBean
> 14:22:09,730 INFO [stdout] (ServerService Thread Pool -- 31) ControlPoint: pause called
> 14:22:09,730 INFO [stdout] (ServerService Thread Pool -- 4) EJBComponent: stopping remote-failover-test:remote-failover-test:StatelessIncrementorBean
> 14:22:09,731 INFO [stdout] (ServerService Thread Pool -- 29) ControlPoint: pause called
> 14:22:09,731 INFO [stdout] (ServerService Thread Pool -- 11) EJBComponent: stopping remote-failover-test:remote-failover-test:ClientIncrementorBean
> 14:22:09,731 INFO [stdout] (ServerService Thread Pool -- 4) ControlPoint: pause called
> 14:22:09,732 INFO [stdout] (ServerService Thread Pool -- 67) ControlPoint: pause called
> 14:22:09,732 INFO [stdout] (ServerService Thread Pool -- 11) ControlPoint: pause called
> 14:22:09,733 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> 14:22:09,735 INFO [stdout] (EJB default - 4) ControlPoint: requestComplete called
> 14:22:09,735 ERROR [org.jboss.as.ejb3] (EJB default - 4) WFLYEJB0150: Could not write method invocation failure for method public abstract org.jboss.as.test.clustering.cluster.ejb.remote.bean.Result org.jboss.as.test.clustering.cluster.ejb.remote.bean.Incrementor.increment() on bean named SlowToDestroyStatefulIncrementorBean for appname modulename remote-failover-test distinctname due to: java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.getWeakAffinity(MethodInvocationMessageHandler.java:269)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$500(MethodInvocationMessageHandler.java:69)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:237)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 14:22:09,736 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 2 entries in 2 milliseconds
> 14:22:09,736 INFO [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-5) EJBCLIENT000016: Channel Channel ID ad5ee733 (outbound) of Remoting connection 29cd434b to /127.0.0.1:8080 can no longer process messages
> 14:22:09,738 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0010: Stopping weld service for deployment remote-failover-test.jar
> 14:22:09,740 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped remote-failover-test.jar cache from ejb container
> 14:22:09,760 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000029: Passivating all entries to disk
> 14:22:09,761 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 29) ISPN000030: Passivated 1 entries in 0 milliseconds
> 14:22:09,762 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment remote-failover-test.jar (runtime-name: remote-failover-test.jar) in 36ms
> 14:22:09,764 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 29) WFLYCLINF0003: Stopped dist cache from ejb container
> 14:22:09,766 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-12) ISPN000080: Disconnecting JGroups channel ejb
> 14:22:09,766 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-12) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 14:22:09,772 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,ee,node-1) ISPN000094: Received new cluster view for channel ejb: [node-1|2] (1) [node-1]
> 14:22:09,807 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /home/nrla/projects/wildfly-git-repo/testsuite/integration/clustering/target/wildfly-SYNC-tcp-0/standalone/data/content/66/642dea2bc32c3ba888dd173db2b91d18b848b0/content
> 14:22:09,807 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "remote-failover-test.jar" (runtime-name: "remote-failover-test.jar")
> {code}
>
> Looking at the use of ControlPoints within EJBs, it seems that on undeployment, the EJBComponent.stop() method calls ControlPoint.pause() only which will cause the interceptor to block any future invocations but also not prevent the undeployment from continuing, despite the fact that a request is active.
> In this case, it seems that once the EJB components have been stopped, the cache entries for their state have been passivated before the invocation has completed.
> Do we need more mechanism for such cases? Like calling some thing on undeployment which will case the control points to be paused as well as allowing active requests to finish, subject to some timeout?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3962:
--------------------------------------
This should be fixed in 9.0.0.Beta1 (assuming it is similar to https://issues.jboss.org/browse/WFLY-4352)
> 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)
11 years, 1 month
[JBoss JIRA] (WFLY-4352) Servlet 3 - async-mode - onComplete not tirggered when JSP is dispatched
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4352?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4352.
----------------------------------
Fix Version/s: 9.0.0.Beta2
Resolution: Done
> Servlet 3 - async-mode - onComplete not tirggered when JSP is dispatched
> ------------------------------------------------------------------------
>
> Key: WFLY-4352
> URL: https://issues.jboss.org/browse/WFLY-4352
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Günther Grill
> Assignee: Stuart Douglas
> Labels: async, asynchronous, jsp, servlet
> Fix For: 9.0.0.Beta2
>
> Attachments: AsyncServlet.war
>
>
> When a JSP is dispatched in a Async-Servlet, the {{AsyncListener#onComplete}} is never triggered.
> {code:title=AsyncServlet.java|borderStyle=solid}
> @WebServlet(urlPatterns = { "/AsyncServlet" }, asyncSupported = true)
> public class AsyncServlet extends HttpServlet {
> public AsyncServlet() {
> super();
> }
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
> res.setContentType("text/html");
> final AsyncContext ac;
> if (req.isAsyncStarted()) {
> ac = req.getAsyncContext();
> } else {
> ac = req.startAsync();
> }
> ac.setTimeout(5000);
> ac.addListener(new AsyncListener() {
> @Override
> public void onTimeout(AsyncEvent event) throws IOException {
> System.out.println("onTimeout");
> }
> @Override
> public void onStartAsync(AsyncEvent event) throws IOException {
> System.out.println("onStartAsync");
> }
> @Override
> public void onError(AsyncEvent event) throws IOException {
> System.out.println("onError");
> }
> @Override
> public void onComplete(AsyncEvent event) throws IOException {
> System.out.println("onComplete");
> }
> });
> System.out.println("Calling JSP...");
> ac.dispatch("/result.jsp");
> System.out.println("After JSP call");
> }
> }
> {code}
> {code:title=result.jsp|borderStyle=solid}
> <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
> pageEncoding="ISO-8859-1"%>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
> <title>AsyncServletTest</title>
> </head>
> <body>
> <p>JSP Content</p>
> <%
> System.out.println("Start JSP");
> Thread.sleep(1000); // sleep 1 seconds
> String resp = (String)request.getAttribute("result");
> resp = resp + "<p>on JSP</p>";
> Thread.sleep(1000); // sleep 1 seconds
> System.out.println("End JSP");
> %>
> <p><%=resp%></p>
> </body>
> </html>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (DROOLS-752) Incremental update leaks globals
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-752:
-----------------------------------
Summary: Incremental update leaks globals
Key: DROOLS-752
URL: https://issues.jboss.org/browse/DROOLS-752
Project: Drools
Issue Type: Feature Request
Components: core engine
Affects Versions: 6.2.0.Final
Environment: Mac OS X 10.10.2, Oracle Hotspot 1.7.0_71
Reporter: Duncan Doyle
Assignee: Mario Fusco
The incremental update feature of Drools allows me to incrementally update not only the KieBase, but also the KieSession. I have a use-case where my updated rules have different globals defined (different classes) than the original rules, with different names.
When I set a global on a KieSession, Drools explicitly checks whether that global is defined in the KieBase, and if not, it will throw an error. However, when I incrementally update the KieBase, and a global is removed from the rulebase, that global is not removed from the MapGlobalResolver map, potentially causing issues (e.g. memory leaks).
When a session is incrementally updated, and globals are no longer defined in the new rule-base, they should be removed from the MapGlobalResolver.
See reproducer here: http://www.github.com/DuncanDoyle/drools-incremental-update-globals-leak
Clone the repo and run 'mvn clean test'.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[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)
11 years, 1 month
[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)
11 years, 1 month
[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)
11 years, 1 month