[JBoss JIRA] (WFLY-4414) Non Standard SESSIONID not clustered
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4414?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4414:
--------------------------------------
What does your mod_cluster config look like? Have you configured the custom sticky session cookie name in the mod_cluster config?
> Non Standard SESSIONID not clustered
> ------------------------------------
>
> Key: WFLY-4414
> URL: https://issues.jboss.org/browse/WFLY-4414
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Robert Smith
> Assignee: Jason Greene
>
> We are using Wildfly 8.1.0-Final in domain mode with mod-cluster.
> We use a non-standard session id in a web application as follows:
> ...
> <distributable />
> <session-config>
> <cookie-config>
> <name>VSOPSESSIONID</name>
> </cookie-config>
> </session-config>
> ...
> During testing of this we had our sticky set to JSESSIONID which caused requests to be forwarded to our 2 nodes alternatively.
> In our 1st request we do:
> request.getSession().setAttribute(KEY, value)
> In our 2nd request we do:
> request.getSession.getAttribute(KEY)
> The second request always returns null.
> When we remove the custom session id, the session data is avaliable.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBJCA-1252) MCPs can become detached
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1252:
--------------------------------------
Summary: MCPs can become detached
Key: JBJCA-1252
URL: https://issues.jboss.org/browse/JBJCA-1252
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2.Final, 1.1.9.Final, 1.0.31.Final
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Priority: Blocker
Fix For: 1.0.32.Final, 1.1.10.Final, 1.2.3.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4413.
----------------------------------
Resolution: Rejected
There is nothing that says we need to immediately close the connection after the request is done. If we did that then browsers would need to create a new connection for every request, which is very slow. If you really want the connection to close immediately for some reason just send a connection:close header.
Note that you can control the amount of time the connection will sit idle before being closed through the 'no-request-timeout' and 'read-timeout' parameters on the HTTP listener in the Undertow subsystem.
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> package com.suning.esb.test;
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4162) Intermittent failure in ExcludeEjbSubsystemTestCase
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4162?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4162.
----------------------------------
Resolution: Out of Date
This has not failed in any of the last ~250 runs. I have a feeling this may have been a problem with arquillian and junit expected exception, when I changed the test to manually catch the expected exception the problem seems to have gone away.
> Intermittent failure in ExcludeEjbSubsystemTestCase
> ---------------------------------------------------
>
> Key: WFLY-4162
> URL: https://issues.jboss.org/browse/WFLY-4162
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Brian Stansberry
> Assignee: Stuart Douglas
>
> Three times in the past 6 weeks, ExcludeEjbSubsystemTestCase has failed due to the expected NamingException not being thrown. All three failures are on Windows.
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullReque...
> Note the failure message is a bit confusing. It's the "Caused by" in the stack trace that shows the NamingException didn't happen:
> {code}
> java.lang.Exception: Unexpected exception, expected<javax.naming.NameNotFoundException> but was<java.lang.AssertionError>
> at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.AssertionError: Expected exception: javax.naming.NameNotFoundException
> at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:129)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:108)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1530)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:748)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> 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:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-729) Android Support
by Mark Kedzierski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ]
Mark Kedzierski updated DROOLS-729:
-----------------------------------
Git Pull Request: https://github.com/mvel/mvel/pull/72, https://github.com/droolsjbpm/drools/pull/416 (was: https://github.com/mvel/mvel/pull/72)
> Android Support
> ---------------
>
> Key: DROOLS-729
> URL: https://issues.jboss.org/browse/DROOLS-729
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Android
> Reporter: Mark Kedzierski
> Assignee: Mario Fusco
> Priority: Optional
> Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Android 5.0 support requires change in mvel2. android 5 doesn't allow overriding the java.version system property. mvel needs to look for an alternate property if that one is not available. One which can be set. I am preparing a pull request for this.
> -using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
> -multiple kjars in dependencies will clobber each other's kmodule.xml. as all jars are merged into a single apk.
> I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-729) Android Support
by Mark Kedzierski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ]
Mark Kedzierski updated DROOLS-729:
-----------------------------------
Description:
I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
code:
http://www.github.com/kedzie/drools-android
Features:
-Dex classloaders for all generated classes
-Roboguice integration for injecting knowledge bases from precompiled packages
-Maven plugin which pre-compiles rule packages
Issues:
-Android 5.0 support requires change in mvel2. android 5 doesn't allow overriding the java.version system property. mvel needs to look for an alternate property if that one is not available. One which can be set. I am preparing a pull request for this.
-using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
-multiple kjars in dependencies will clobber each other's kmodule.xml. as all jars are merged into a single apk.
I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
was:
I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
code:
http://www.github.com/kedzie/drools-android
http://www.github.com/kedzie/drools-android-sample
Features:
-Dex classloaders for all generated classes
-Roboguice integration for injecting knowledge bases from precompiled packages
-Maven plugin which pre-compiles rule packages
Issues:
-Android 5.0 support requires change in mvel2. android 5 doesn't allow overriding the java.version system property. mvel needs to look for an alternate property if that one is not available. One which can be set. I am preparing a pull request for this.
-using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
-multiple kjars in dependencies will clobber each other's kmodule.xml. as all jars are merged into a single apk.
I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
> Android Support
> ---------------
>
> Key: DROOLS-729
> URL: https://issues.jboss.org/browse/DROOLS-729
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Android
> Reporter: Mark Kedzierski
> Assignee: Mario Fusco
> Priority: Optional
> Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Android 5.0 support requires change in mvel2. android 5 doesn't allow overriding the java.version system property. mvel needs to look for an alternate property if that one is not available. One which can be set. I am preparing a pull request for this.
> -using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
> -multiple kjars in dependencies will clobber each other's kmodule.xml. as all jars are merged into a single apk.
> I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months