[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv commented on WFLY-4413:
------------------------------------
[~swd847]: I have also confirmed that the connection won't be leak in the tomcat. Could you please confirm whether it is a bug in the undertow and need to be resolved?
Thanks a lot!
Jeremy
> 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, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv edited comment on WFLY-4413 at 3/9/15 7:42 AM:
------------------------------------------------------------
Dear [~swd847]:
I have also confirmed that the connection won't be leak in the tomcat. Could you please confirm whether it is a bug in the undertow and need to be resolved?
Thanks a lot!
Jeremy
was (Author: jeremy_lv):
[~swd847]: I have also confirmed that the connection won't be leak in the tomcat. Could you please confirm whether it is a bug in the undertow and need to be resolved?
Thanks a lot!
Jeremy
> 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, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv updated WFLY-4413:
-------------------------------
Description:
{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}
was:
{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 10 seconds to simulate the business logic.
Thread.sleep(5000);
ctx.complete();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
{code}
> 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, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
jeremy_lv lv updated WFLY-4413:
-------------------------------
Steps to Reproduce:
*The reproduced steps are as follows:*
{panel:title=Reproduced steps|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
*Step1.* Compile the AsyncDemoServlet.java I have provided
and export a war file called test.war.
*Step2.* Deploy the test.war to the wildfly.
*Step3.* check the current connection leak number and
you will found the current connection leak number is 0
Notice: you can use
"lsof -p pid | grep "can't identify protocol" |wc -l"
to check the current connection leak number.
*Step4.* Access the asynchronous servlet application.
i.e: if you deployed the test.war in your local application server,
and your defalt http listener port is 8000, you can just enter the
url as http://localhost:8080/test/asyncDemoServlet in your browser
to access the web application.
*Step5.* Click the "Esc" button in your keyboards in five seconds
to terminated the http request.
*Step6.* check the current connection leak number and
you will found the current connection leak number has
been increased by 1.
Notice: you can use
"lsof -p pid | grep "can't identify protocol" |wc -l"
to check the current connection leak number.
{panel}
was:
*The reproduced steps are as follows:*
{panel:title=Reproduced steps|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
*Step1.* Compile the AsyncDemoServlet.java I have provided here and export a war file called test.war.
*Step2.* Deploy the test.war to the wildfly.
*Step3.* check the current connection leak number and
you will found the current connection leak number is 0
Notice: you can use
"lsof -p pid | grep "can't identify protocol" |wc -l"
to check the current connection leak number.
*Step4.* Access the asynchronous servlet application.
i.e: if you deployed the test.war in your local application server,
and your defalt http listener port is 8000, you can just enter the
url as http://localhost:8080/test/asyncDemoServlet in your browser
to access the web application.
*Step5.* Click the "Esc" button in your keyboards in five seconds
to terminated the http request.
*Step6.* check the current connection leak number and
you will found the current connection leak number has
been increased by 1.
Notice: you can use
"lsof -p pid | grep "can't identify protocol" |wc -l"
to check the current connection leak number.
{panel}
> 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 10 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, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by jeremy_lv lv (JIRA)
jeremy_lv lv created WFLY-4413:
----------------------------------
Summary: 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.2.0.Final, 8.1.0.Final
Environment: Linux
Reporter: jeremy_lv lv
Assignee: Stuart Douglas
Priority: Blocker
{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 10 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, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4397) WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
by Wind Wild (JIRA)
[ https://issues.jboss.org/browse/WFLY-4397?page=com.atlassian.jira.plugin.... ]
Wind Wild commented on WFLY-4397:
---------------------------------
Hi,Stuart Douglas
Thanks for your reply firstly.
My jmeter script as following:
<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="2.6" jmeter="2.11 r1554548">
<hashTree>
<TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
<stringProp name="TestPlan.comments"></stringProp>
<boolProp name="TestPlan.functional_mode">false</boolProp>
<boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
<elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp>
<stringProp name="TestPlan.user_define_classpath"></stringProp>
</TestPlan>
<hashTree>
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
<stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
<elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
<boolProp name="LoopController.continue_forever">false</boolProp>
<intProp name="LoopController.loops">-1</intProp>
</elementProp>
<stringProp name="ThreadGroup.num_threads">50</stringProp>
<stringProp name="ThreadGroup.ramp_time"></stringProp>
<longProp name="ThreadGroup.start_time">1425010031000</longProp>
<longProp name="ThreadGroup.end_time">1425010031000</longProp>
<boolProp name="ThreadGroup.scheduler">false</boolProp>
<stringProp name="ThreadGroup.duration"></stringProp>
<stringProp name="ThreadGroup.delay"></stringProp>
</ThreadGroup>
<hashTree>
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="HTTP Request" enabled="true">
<elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
<collectionProp name="Arguments.arguments"/>
</elementProp>
<stringProp name="HTTPSampler.domain">10.19.220.172</stringProp>
<stringProp name="HTTPSampler.port">8080</stringProp>
<stringProp name="HTTPSampler.connect_timeout"></stringProp>
<stringProp name="HTTPSampler.response_timeout"></stringProp>
<stringProp name="HTTPSampler.protocol"></stringProp>
<stringProp name="HTTPSampler.contentEncoding"></stringProp>
<stringProp name="HTTPSampler.path">/payload/asyncDemoServlet</stringProp>
<stringProp name="HTTPSampler.method">GET</stringProp>
<boolProp name="HTTPSampler.follow_redirects">true</boolProp>
<boolProp name="HTTPSampler.auto_redirects">false</boolProp>
<boolProp name="HTTPSampler.use_keepalive">true</boolProp>
<boolProp name="HTTPSampler.DO_MULTIPART_POST">false</boolProp>
<boolProp name="HTTPSampler.monitor">false</boolProp>
<stringProp name="HTTPSampler.embedded_url_re"></stringProp>
</HTTPSamplerProxy>
<hashTree/>
<ResultCollector guiclass="StatVisualizer" testclass="ResultCollector" testname="Aggregate Report" enabled="true">
<boolProp name="ResultCollector.error_logging">false</boolProp>
<objProp>
<name>saveConfig</name>
<value class="SampleSaveConfiguration">
<time>true</time>
<latency>true</latency>
<timestamp>true</timestamp>
<success>true</success>
<label>true</label>
<code>true</code>
<message>true</message>
<threadName>true</threadName>
<dataType>true</dataType>
<encoding>false</encoding>
<assertions>true</assertions>
<subresults>true</subresults>
<responseData>false</responseData>
<samplerData>false</samplerData>
<xml>false</xml>
<fieldNames>false</fieldNames>
<responseHeaders>false</responseHeaders>
<requestHeaders>false</requestHeaders>
<responseDataOnError>false</responseDataOnError>
<saveAssertionResultsFailureMessage>false</saveAssertionResultsFailureMessage>
<assertionsResultsToSave>0</assertionsResultsToSave>
<bytes>true</bytes>
</value>
</objProp>
<stringProp name="filename"></stringProp>
</ResultCollector>
<hashTree/>
<ResultCollector guiclass="SummaryReport" testclass="ResultCollector" testname="Summary Report" enabled="true">
<boolProp name="ResultCollector.error_logging">false</boolProp>
<objProp>
<name>saveConfig</name>
<value class="SampleSaveConfiguration">
<time>true</time>
<latency>true</latency>
<timestamp>true</timestamp>
<success>true</success>
<label>true</label>
<code>true</code>
<message>true</message>
<threadName>true</threadName>
<dataType>true</dataType>
<encoding>false</encoding>
<assertions>true</assertions>
<subresults>true</subresults>
<responseData>false</responseData>
<samplerData>false</samplerData>
<xml>false</xml>
<fieldNames>false</fieldNames>
<responseHeaders>false</responseHeaders>
<requestHeaders>false</requestHeaders>
<responseDataOnError>false</responseDataOnError>
<saveAssertionResultsFailureMessage>false</saveAssertionResultsFailureMessage>
<assertionsResultsToSave>0</assertionsResultsToSave>
<bytes>true</bytes>
</value>
</objProp>
<stringProp name="filename"></stringProp>
</ResultCollector>
<hashTree/>
<ResultCollector guiclass="ViewResultsFullVisualizer" testclass="ResultCollector" testname="View Results Tree" enabled="true">
<boolProp name="ResultCollector.error_logging">false</boolProp>
<objProp>
<name>saveConfig</name>
<value class="SampleSaveConfiguration">
<time>true</time>
<latency>true</latency>
<timestamp>true</timestamp>
<success>true</success>
<label>true</label>
<code>true</code>
<message>true</message>
<threadName>true</threadName>
<dataType>true</dataType>
<encoding>false</encoding>
<assertions>true</assertions>
<subresults>true</subresults>
<responseData>false</responseData>
<samplerData>false</samplerData>
<xml>false</xml>
<fieldNames>false</fieldNames>
<responseHeaders>false</responseHeaders>
<requestHeaders>false</requestHeaders>
<responseDataOnError>false</responseDataOnError>
<saveAssertionResultsFailureMessage>false</saveAssertionResultsFailureMessage>
<assertionsResultsToSave>0</assertionsResultsToSave>
<bytes>true</bytes>
</value>
</objProp>
<stringProp name="filename"></stringProp>
</ResultCollector>
<hashTree/>
</hashTree>
</hashTree>
</hashTree>
</jmeterTestPlan>
you can test again,when you stop the request,you can watch the file-hander use command "lsof -p pid | can't identify protocol | wc -l",maybe you can see there are lots of "can't identify protocol".
I'm looking forward to your reply,thank you!
> WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
> -----------------------------------------------------------------
>
> Key: WFLY-4397
> URL: https://issues.jboss.org/browse/WFLY-4397
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1
> Environment: Java(TM) SE Runtime Environment (build 1.7.0_25)
> Reporter: Wind Wild
> Assignee: Stuart Douglas
>
> Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following:
>
> 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files)
> at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
>
> 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb
> 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string
> 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3)
> 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms
>
> From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following:
> java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol
> java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol
> java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol
> java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol
> java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol
> java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol
> java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol
> java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol
> java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol
> java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol
> java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol
> java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol
> java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED)
>
> So i know there maybe occur connection leak on WildFly, and i made a test as follow:
> I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it.
>
> Moreover, i found a issue is like above problem:
> [WFLY-3652] Network connection leak - JBoss Issue Tracker
>
> but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1.
>
> Who can help me solve this problem? thanks!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4405) NPE in AstValue.setValue()
by Christer Bernérus (JIRA)
[ https://issues.jboss.org/browse/WFLY-4405?page=com.atlassian.jira.plugin.... ]
Christer Bernérus commented on WFLY-4405:
-----------------------------------------
Last week i dug deeper into this, so I'm pretty sure about what has triggered this behaviour.
I have found a solution for myself working around this, by creating a BeanInfo class, but my analysis might be give some input for thoughts for correcting some possibly very old code.
In my code I have wrapped the properties in the beans using a generic class that acts like a lazily evaluating cache. So every access to the actual property values goes through the
getValue() and setValue() methods of that class.
The problem is that the return type of getValue() is T or essentially "object", and that setValue() is a multiply overloaded method that takes String, Boolean, Integer, DateTime or whatever.
(I'm aware that this, most likely isn't the kosher way of baking beans, but it has worked fine until now :)
The elResolver.getType(ctx, t.base, property) in the code above call is used by AstValue to determine the type of the property, and a few levels down, via ValueExpressionAnalyzer$InterceptingElResolver and DemuxCompositElResolver, it lands in the method BeanELResolver.getType() which after fetching a BeanProperty regards the EL Context as resolved, and then goes on returning whatever the BeanProperty.getPropertyType() returns.
{code: title=BeanELResolver.java|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
/**
* If the base object is not <code>null</code>, returns the most
* general acceptable type that can be set on this bean property.
*
* <p>If the base is not <code>null</code>, the
* <code>propertyResolved</code> property of the <code>ELContext</code>
* object must be set to <code>true</code> by this resolver, before
* returning. If this property is not <code>true</code> after this
* method is called, the caller should ignore the return value.</p>
*
* <p>The provided property will first be coerced to a <code>String</code>.
* If there is a <code>BeanInfoProperty</code> for this property and
* there were no errors retrieving it, the <code>propertyType</code> of
* the <code>propertyDescriptor</code> is returned. Otherwise, a
* <code>PropertyNotFoundException</code> is thrown.</p>
*
* @param context The context of this evaluation.
* @param base The bean to analyze.
* @param property The name of the property to analyze. Will be coerced to
* a <code>String</code>.
* @return If the <code>propertyResolved</code> property of
* <code>ELContext</code> was set to <code>true</code>, then
* the most general acceptable type; otherwise undefined.
* @throws NullPointerException if context is <code>null</code>
* @throws PropertyNotFoundException if <code>base</code> is not
* <code>null</code> and the specified property does not exist
* or is not readable.
* @throws ELException if an exception was thrown while performing
* the property or variable resolution. The thrown exception
* must be included as the cause property of this exception, if
* available.
*/
public Class<?> getType(ELContext context,
Object base,
Object property) {
if (context == null) {
throw new NullPointerException();
}
if (base == null || property == null){
return null;
}
BeanProperty bp = getBeanProperty(context, base, property);
context.setPropertyResolved(true);
return bp.getPropertyType();
}
{code}
Going further down looking at BeanProperty.getPropertyType() it calls the getPropertyType() of its descriptor which in my case goes to PropertyDescriptor.getPropertyType()
{code:title=java.beans.PropertyDescriptor.java|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
/**
* Returns the Java type info for the property.
* Note that the {@code Class} object may describe
* primitive Java types such as {@code int}.
* This type is returned by the read method
* or is used as the parameter type of the write method.
* Returns {@code null} if the type is an indexed property
* that does not support non-indexed access.
*
* @return the {@code Class} object that represents the Java type info,
* or {@code null} if the type cannot be determined
*/
public synchronized Class<?> getPropertyType() {
Class<?> type = getPropertyType0();
if (type == null) {
try {
type = findPropertyType(getReadMethod(), getWriteMethod());
setPropertyType(type);
} catch (IntrospectionException ex) {
// Fall
}
}
return type;
}
{code}
In my case, there is no type reference to the property (this is where I assume my BeanInfo solution kicks in), so getPropertyType0() returns null, and the method goes into introspection via the call to findPropertyType(). Here's the code:
{code:title=java.beans.PropertyDescriptor.java|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
/**
* Returns the property type that corresponds to the read and write method.
* The type precedence is given to the readMethod.
*
* @return the type of the property descriptor or null if both
* read and write methods are null.
* @throws IntrospectionException if the read or write method is invalid
*/
private Class<?> findPropertyType(Method readMethod, Method writeMethod)
throws IntrospectionException {
Class<?> propertyType = null;
try {
if (readMethod != null) {
Class<?>[] params = getParameterTypes(getClass0(), readMethod);
if (params.length != 0) {
throw new IntrospectionException("bad read method arg count: "
+ readMethod);
}
propertyType = getReturnType(getClass0(), readMethod);
if (propertyType == Void.TYPE) {
throw new IntrospectionException("read method " +
readMethod.getName() + " returns void");
}
}
if (writeMethod != null) {
Class<?>[] params = getParameterTypes(getClass0(), writeMethod);
if (params.length != 1) {
throw new IntrospectionException("bad write method arg count: "
+ writeMethod);
}
if (propertyType != null && !params[0].isAssignableFrom(propertyType)) {
throw new IntrospectionException("type mismatch between read and write methods");
}
propertyType = params[0];
}
} catch (IntrospectionException ex) {
throw ex;
}
return propertyType;
}
{code}
This introspecting code first determines the type of the property by looking at what the getter returns (the readMethod in the codei).
This seems plausible, as one cannot overload methods returning different types in java. Then it looks at the setter method (and it implicitly assumes there is only one setter, but I can cope with that)
Then it checks the parameter count of the setter, which should be 1, fine.
But finally there is a type check between the getter and the setter, which _might_ not be completely accurate:
{code}
if (propertyType != null && !params[0].isAssignableFrom(propertyType)) {
throw new IntrospectionException("type mismatch between read and write methods");
}
{code}
As I interpret this, the code checks if the type returned by the getter, can be used to set the value of the property.
This may actually have been the intention, but in my case, it would have helped if the test had been the other way round, i.e. testing whether the setter is able to set a value of the type returned by the getter.
So the scenario that happened here is that the getter/setter test failed, causing an IntrospectionException which was *swallowed* by the catch in the propertyDescriptor.getPropertyType() method and replaced by a null return.
This null return then bubbles back to {{AstValue.setValue()}} setting {{targetType}} to null and while the context is flagged as resolved, AstValue.setValue() then unresolves the property and the call to convertToType simply returns null and does not change its resolved status, and then 5 lines below the method tries to use {{targetType}} as an object pointer because {{value}} is also null in my case.
So here are three questions to ponder over:
1. Is the getter/setter type comparison correct?
2. Is it really nice to swallow the IntrospectionException in PropertyDescriptor.getPropertyType()
3. What should happen in AstValue.setValue() when targetType is evaluated to null? NPE hurts.
-- Chris
> NPE in AstValue.setValue()
> --------------------------
>
> Key: WFLY-4405
> URL: https://issues.jboss.org/browse/WFLY-4405
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.2.0.Final
> Environment: MacOS X, RHEL6
> Reporter: Christer Bernérus
> Assignee: Farah Juma
>
> When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue().
> The code where this happens is in javax.el-3.0.1-b05.jar and looks like this:
> {code:title=AstValue.java|borderStyle=solid}
> /* Note by kchung 10/2013
> * The spec does not say if the value should be cocerced to the target
> * type before setting the value to the target. The conversion is kept
> * here to be backward compatible.
> */
> ctx.setPropertyResolved(false);
> Class<?> targetType = elResolver.getType(ctx, t.base, property);
> if (ctx.isPropertyResolved()) {
> ctx.setPropertyResolved(false);
> Object targetValue = elResolver.convertToType(ctx, value, targetType);
> if (ctx.isPropertyResolved()) {
> value = targetValue;
> } else {
> if (value != null || targetType.isPrimitive()) {
> value = ELSupport.coerceToType(value, targetType);
> }
> }
> }
> {code}
> From my debugging session, I have seen that the code in
> {{elResolver.getType()}} may return null, which happens to me,
> but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE.
> Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-3352) Failure to restore persistent session triggers http 500 on all requests
by Olivier M (JIRA)
[ https://issues.jboss.org/browse/WFLY-3352?page=com.atlassian.jira.plugin.... ]
Olivier M commented on WFLY-3352:
---------------------------------
I add <distributable/> in my web.xml.
Removing it resolved the problem.
> Failure to restore persistent session triggers http 500 on all requests
> -----------------------------------------------------------------------
>
> Key: WFLY-3352
> URL: https://issues.jboss.org/browse/WFLY-3352
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR1, 9.0.0.Alpha1
> Reporter: Emond Papegaaij
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
> Attachments: jira-generated-image-static-bug-cab284e5-c93b-408c-a534-05e2872525b0, jira-generated-image-static-comment-icon-d64a5caa-6ca9-4ffb-a4cb-b3bb81eaa80b, jira-generated-image-static-footer-desktop-logo-0361006c-9dc5-4d5f-af33-776bcc11b746
>
>
> When persistent-sessions is enabled and an incompatible change in the class hierarchy makes it impossible to restore a session after updating the application, the owner of the session must clear his cookies to be able to use the application again. On an incoming request, InfinispanSessionManager tries to reactivate the session, which fails with the exception below. Rather than discarding the corrupted session and creating a new one, the user is presented an http 500 error and is unable to continue. Only after removing the JSESSIONID cookie is the user able to use the application.
> This issue is related to WFLY-2729, which is about the way the problem is reported in the logs. This issue is about how the user is affected.
> {code}
> 08:09:11,430 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-56) ISPN000136: Execution error: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.IllegalArgumentException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(org.infinispan.notifications.cachelistener.event.CacheEntryActivatedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager@65ffd82d
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:211) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:229) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:192) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryActivated(CacheNotifierImpl.java:355) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.ActivationInterceptor.sendNotification(ActivationInterceptor.java:109) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.recordLoadedEntry(CacheLoaderInterceptor.java:325) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:278) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.ActivationInterceptor.loadIfNeeded(ActivationInterceptor.java:86) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeededAndUpdateStats(CacheLoaderInterceptor.java:335) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:105) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:116) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitGetKeyValueCommand(PessimisticLockingInterceptor.java:72) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:226) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.CacheImpl.get(CacheImpl.java:377) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-02-10 20:13]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-02-10 20:13]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-02-10 20:13]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.10.Final.jar:1.0.10.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.10.Final.jar:1.0.10.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> Caused by: java.lang.IllegalArgumentException: java.io.InvalidClassException: nl.topicus.eduario.web.pages.StudentHomePage$1; Class does not extend stream superclass
> at org.wildfly.clustering.web.infinispan.session.MarshalledValueSessionAttributeMarshaller.read(MarshalledValueSessionAttributeMarshaller.java:48)
> at org.wildfly.clustering.web.infinispan.session.MarshalledValueSessionAttributeMarshaller.read(MarshalledValueSessionAttributeMarshaller.java:33)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributes(CoarseImmutableSessionAttributes.java:46)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.activated(InfinispanSessionManager.java:211)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_55]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_55]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:207) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> ... 64 more
> Caused by: java.io.InvalidClassException: nl.topicus.eduario.web.pages.StudentHomePage$1; Class does not extend stream superclass
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:960)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1712)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1628)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1269)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1536)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1575)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:326)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1712)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1628)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1591)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1269)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)
> at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:773)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:649)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:149)
> at org.jboss.marshalling.river.BlockUnmarshaller.readObject(BlockUnmarshaller.java:135)
> at org.jboss.marshalling.MarshallerObjectInputStream.readObjectOverride(MarshallerObjectInputStream.java:53)
> at org.jboss.marshalling.river.RiverObjectInputStream.readObjectOverride(RiverObjectInputStream.java:307)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:364) [rt.jar:1.7.0_55]
> at org.apache.wicket.page.PageStoreManager$SessionEntry.readObject(PageStoreManager.java:274) [wicket-core-6.15.0.jar:6.15.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_55]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_55]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_55]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_55]
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1608)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1269)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadMapObject(RiverUnmarshaller.java:195)
> at org.jboss.marshalling.river.RiverUnmarshaller.readMapData(RiverUnmarshaller.java:819)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:682)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.as.clustering.marshalling.SimpleMarshalledValue.get(SimpleMarshalledValue.java:101)
> at org.jboss.as.clustering.marshalling.SimpleMarshalledValue.get(SimpleMarshalledValue.java:45)
> at org.wildfly.clustering.web.infinispan.session.MarshalledValueSessionAttributeMarshaller.read(MarshalledValueSessionAttributeMarshaller.java:46)
> ... 75 more
> Caused by: an exception which occurred:
> in field data
> in object of type nl.topicus.eduario.web.pages.StudentHomePage$2
> in element at index [6] of size [7]
> in field children
> in object of type nl.topicus.eduario.web.pages.StudentHomePage
> in element at index [0] of size [1]
> in object of type org.apache.wicket.page.PageStoreManager$SessionEntry
> in map value at index [8] of size [11]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4412) Not able to enable JMX Remote access
by Shark Xu (JIRA)
[ https://issues.jboss.org/browse/WFLY-4412?page=com.atlassian.jira.plugin.... ]
Shark Xu commented on WFLY-4412:
--------------------------------
Not sure whether this is due to the Logging system not ready when init jmx?
> Not able to enable JMX Remote access
> ------------------------------------
>
> Key: WFLY-4412
> URL: https://issues.jboss.org/browse/WFLY-4412
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, ConfigAdmin
> Affects Versions: 8.2.0.Final
> Environment: windows & linux
> Reporter: Shark Xu
> Assignee: David Lloyd
>
> Can not enable JMX remote access port.
> Config in domain.xml:
> <jvm-options>
> <option value="-Dcom.sun.management.jmxremote.port=19999"/>
> <option value="-Dcom.sun.management.jmxremote.authenticate=false"/>
> <option value="-Dcom.sun.management.jmxremote.ssl=false"/>
> </jvm-options>
> java.lang.IllegalStateException raised during startup.
> Logs:
> [Server:server-one] Exception in thread "main" java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util
> .logging.manager" system property to "org.jboss.logmanager.LogManager")
> [Server:server-one] at org.jboss.logmanager.Logger.getLogger(Logger.java:61)
> [Server:server-one] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:86)
> [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [Server:server-one] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:server-one] at java.lang.reflect.Method.invoke(Method.java:606)
> [Server:server-one] at org.jboss.modules.Module.run(Module.java:312)
> [Server:server-one] at org.jboss.modules.Main.main(Main.java:460)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0
[JBoss JIRA] (WFLY-4412) Not able to enable JMX Remote access
by Shark Xu (JIRA)
Shark Xu created WFLY-4412:
------------------------------
Summary: Not able to enable JMX Remote access
Key: WFLY-4412
URL: https://issues.jboss.org/browse/WFLY-4412
Project: WildFly
Issue Type: Bug
Components: Class Loading, ConfigAdmin
Affects Versions: 8.2.0.Final
Environment: windows & linux
Reporter: Shark Xu
Assignee: David Lloyd
Can not enable JMX remote access port.
Config in domain.xml:
<jvm-options>
<option value="-Dcom.sun.management.jmxremote.port=19999"/>
<option value="-Dcom.sun.management.jmxremote.authenticate=false"/>
<option value="-Dcom.sun.management.jmxremote.ssl=false"/>
</jvm-options>
java.lang.IllegalStateException raised during startup.
Logs:
[Server:server-one] Exception in thread "main" java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util
.logging.manager" system property to "org.jboss.logmanager.LogManager")
[Server:server-one] at org.jboss.logmanager.Logger.getLogger(Logger.java:61)
[Server:server-one] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:86)
[Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[Server:server-one] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[Server:server-one] at java.lang.reflect.Method.invoke(Method.java:606)
[Server:server-one] at org.jboss.modules.Module.run(Module.java:312)
[Server:server-one] at org.jboss.modules.Main.main(Main.java:460)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
- 1
- 0