[JBoss JIRA] (WFLY-3895) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3895?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3895:
--------------------------------------
You are going to need to provide more details. Can you email undertow-dev(a)lists.jboss.org with more details about your code? By your description and looking at the stack trace it kinda looks like something is trying to write to the first request which as already ended.
> Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
> -----------------------------------------------------------------
>
> Key: WFLY-3895
> URL: https://issues.jboss.org/browse/WFLY-3895
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> This happens with an Http POST request for a Jolokia MBean operation.
> Attribute reads seem to work.
> {code}
> 10:28:10,823 ERROR [io.undertow.request] (default task-3) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1952)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:146)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:588)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1404)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:193)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened
by Jose Luis Melgar (JIRA)
[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ]
Jose Luis Melgar updated DROOLS-672:
------------------------------------
Description:
On behalf of Gergely Bacso:
{quote}
From: Mark Proctor
Sent: 20/12/2014 21:15
To: drools-setup(a)googlegroups.com
Cc: Bob Brodt
Subject: Re: [drools-setup] Drools audit log view cannot be opened
please open a JIRA, so we can be sure to fix this.
Thanks
Mark
{quote}
{quote}
On 19 Dec 2014, at 18:19, Gergely Bacsó wrote:
Hi,
First of all: this problem can be reproduced with only a single audit file.
I managed to get closer to the solution by spending a few hours reading Drools source code:
The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up:
http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop())
Since my audit logs for some reason contain several of
AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays.
Gergely
{quote}
was:
On behalf of Gergely Bacso:
{quote}
From: Mark Proctor
Sent: 20/12/2014 21:15
To: drools-setup(a)googlegroups.com
Cc: Bob Brodt
Subject: Re: [drools-setup] Drools audit log view cannot be opened
please open a JIRA, so we can be sure to fix this.
Thanks
Mark
{quote}
{quote}
On 19 Dec 2014, at 18:19, Gergely Bacsó <gergely.bacso(a)gmail.com> wrote:
Hi,
First of all: this problem can be reproduced with only a single audit file.
I managed to get closer to the solution by spending a few hours reading Drools source code:
The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up:
http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop())
Since my audit logs for some reason contain several of
AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays.
Gergely
{quote}
> Drools audit log view cannot be opened
> --------------------------------------
>
> Key: DROOLS-672
> URL: https://issues.jboss.org/browse/DROOLS-672
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Reporter: Jose Luis Melgar
> Assignee: Mark Proctor
> Labels: Drools
>
> On behalf of Gergely Bacso:
> {quote}
> From: Mark Proctor
> Sent: 20/12/2014 21:15
> To: drools-setup(a)googlegroups.com
> Cc: Bob Brodt
> Subject: Re: [drools-setup] Drools audit log view cannot be opened
> please open a JIRA, so we can be sure to fix this.
> Thanks
> Mark
> {quote}
> {quote}
> On 19 Dec 2014, at 18:19, Gergely Bacsó wrote:
> Hi,
> First of all: this problem can be reproduced with only a single audit file.
> I managed to get closer to the solution by spending a few hours reading Drools source code:
> The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up:
> http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop())
> Since my audit logs for some reason contain several of
> AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays.
> Gergely
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened
by Jose Luis Melgar (JIRA)
Jose Luis Melgar created DROOLS-672:
---------------------------------------
Summary: Drools audit log view cannot be opened
Key: DROOLS-672
URL: https://issues.jboss.org/browse/DROOLS-672
Project: Drools
Issue Type: Bug
Affects Versions: 6.0.1.Final
Reporter: Jose Luis Melgar
Assignee: Mark Proctor
On behalf of Gergely Bacso:
{quote}
From: Mark Proctor
Sent: 20/12/2014 21:15
To: drools-setup(a)googlegroups.com
Cc: Bob Brodt
Subject: Re: [drools-setup] Drools audit log view cannot be opened
please open a JIRA, so we can be sure to fix this.
Thanks
Mark
{quote}
{quote}
On 19 Dec 2014, at 18:19, Gergely Bacsó <gergely.bacso(a)gmail.com> wrote:
Hi,
First of all: this problem can be reproduced with only a single audit file.
I managed to get closer to the solution by spending a few hours reading Drools source code:
The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up:
http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop())
Since my audit logs for some reason contain several of
AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays.
Gergely
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4187) Cloning org.jboss.invocation.InterceptorContext leaks memory
by Jeroen Wielandt (JIRA)
[ https://issues.jboss.org/browse/WFLY-4187?page=com.atlassian.jira.plugin.... ]
Jeroen Wielandt updated WFLY-4187:
----------------------------------
Affects Version/s: 8.2.0.Final
> Cloning org.jboss.invocation.InterceptorContext leaks memory
> ------------------------------------------------------------
>
> Key: WFLY-4187
> URL: https://issues.jboss.org/browse/WFLY-4187
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Jeroen Wielandt
> Assignee: Jason Greene
>
> The clone function uses sublist to set the new list of interceptors.
> public InterceptorContext clone() {
> ....
> clone.setInterceptors(interceptors.subList(next, interceptors.size()));
> return clone;
> }
> This will keep a reference to the original list around. So the original list will never be released. Chaining clone multiple times will eventually cause an out of memory because each sublist grows slightly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3895) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
by Karthick Jaganathan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3895?page=com.atlassian.jira.plugin.... ]
Karthick Jaganathan commented on WFLY-3895:
-------------------------------------------
No, I'm not trying to write data after the exchange has ended.
To provide more context: My application is a simple REST application that responds to requests. I use curl to POST data and get responses. For the first time, after the applicaiton is started, the request and response works fine. Subsequent Requests gets into this state (Error on server). Any other clues?
Thank You -Karthick
> Blocking request failed HttpServerExchange{ POST /fabric/jolokia}
> -----------------------------------------------------------------
>
> Key: WFLY-3895
> URL: https://issues.jboss.org/browse/WFLY-3895
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> This happens with an Http POST request for a Jolokia MBean operation.
> Attribute reads seem to work.
> {code}
> 10:28:10,823 ERROR [io.undertow.request] (default task-3) Blocking request failed HttpServerExchange{ POST /fabric/jolokia}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1952)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:146)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:588)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1404)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:193)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4088) NPE when changing scheduled service
by Stephen Buergler (JIRA)
[ https://issues.jboss.org/browse/WFLY-4088?page=com.atlassian.jira.plugin.... ]
Stephen Buergler commented on WFLY-4088:
----------------------------------------
I got this too. When I rename the Scheduled method, org.jboss.as.ejb3.timerservice.CalendarTimer.getTimeoutMethod can't match the name in the xml to the name on the method and it returns null. I guess the code that eventually uses this information doesn't handle null correctly.
> NPE when changing scheduled service
> -----------------------------------
>
> Key: WFLY-4088
> URL: https://issues.jboss.org/browse/WFLY-4088
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Alarik Myrin
> Assignee: David Lloyd
>
> If I modify or remove a (persistent) scheduled service, I get the following stack trace:
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> ... 3 more
> Another user is reporting the same thing on 8.1.0 Final, see:
> http://stackoverflow.com/questions/25988818/deploying-java-schedule-with-...
> Is there any way using the CLI to delete persistent scheduled services?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years