[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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months
[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:
--------------------------------------
This is not related to this bug (which was related to a bug in the way 100-continue requests were handled), is it possible you are trying to write data to the response after the exchange has 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)
11 years, 7 months
[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:
-------------------------------------------
Hi Stuart,
I'm using "undertow-core-1.2.0.Beta6.jar". The exact I get is below:
-----
SEVERE: UT000004: getResponseChannel() has already been called
java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:208)
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:294)
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:270)
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:300)
.....
.....
.....
.....
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1181)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
at com.google.common.util.concurrent.Futures$ChainingListenableFuture$1.run(Futures.java:872)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.Futures$ImmediateFuture.addListener(Futures.java:102)
at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:868)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297)
at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
at com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:105)
at com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:246)
at com.datastax.driver.core.RequestHandler.onSet(RequestHandler.java:278)
at com.datastax.driver.core.Connection$Dispatcher.messageReceived(Connection.java:661)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
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)
-----
> 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)
11 years, 7 months
[JBoss JIRA] (WFCORE-485) Standalone.bat not support log dir with spaces in path (jboss.server.log.dir)
by Duc Quoc (JIRA)
[ https://issues.jboss.org/browse/WFCORE-485?page=com.atlassian.jira.plugin... ]
Duc Quoc commented on WFCORE-485:
---------------------------------
I've checked the new script on 8.1.0.Final and jboss-eap-6.2. It works both !
Thank you :) .
> Standalone.bat not support log dir with spaces in path (jboss.server.log.dir)
> -----------------------------------------------------------------------------
>
> Key: WFCORE-485
> URL: https://issues.jboss.org/browse/WFCORE-485
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Scripts
> Environment: Windows 7
> Reporter: Duc Quoc
> Assignee: James Perkins
> Priority: Minor
> Fix For: 1.0.0.Alpha14
>
>
> I tried to specify a custom log folder for WildFly, by overriding property jboss.server.log.dir
> https://docs.jboss.org/author/display/WFLY8/Command+line+parameters
> But it only works for folder without space in path. The ones with space when used with "jboss.server.log.dir" will prevent wildfly from starting.
> Working:
> C:\>start C:\wildfly-8.1.0.Final\bin\standalone.bat
> C:\>start C:\wildfly-8.1.0.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Windows"
> Not working (server can not start):
> C:\>start C:\wildfly-8.1.0.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> (More info:
> JBoss AS 7.1 works:
> C:\> start C:\jboss-as-7.1.1.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> JBoss EAP 6 and WildFly 8.0 not working either:
> C:\> start C:\jboss-eap-6.2\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> C:\> start C:\wildfly-8.0.0.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> Aready tried setting jboss.server.log.dir="C:\Program Files" in JAVA_OPTS but did not work either. Should have been fixed in WFLY-1358 or WFLY-2348.
> )
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[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:
--------------------------------------
This should be fixed, which version are you using?
> 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)
11 years, 7 months