[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)
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:
-------------------------------------------
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)
10 years
[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)
10 years
[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)
10 years
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4196:
--------------------------------------
This sounds like a bug in the filter, if you are modifying the length of the response (e.g. by compressing content) then you need to make sure you clear the content length header if it has been set.
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Nicolas Cazottes (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Nicolas Cazottes updated WFLY-4196:
-----------------------------------
Attachment: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war
fiddler_protocol_violation.jpg
War to reproduce the problem
Screenshot of fiddler
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Nicolas Cazottes (JIRA)
Nicolas Cazottes created WFLY-4196:
--------------------------------------
Summary: HTTP protocol violation
Key: WFLY-4196
URL: https://issues.jboss.org/browse/WFLY-4196
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final, 8.1.0.Final
Reporter: Nicolas Cazottes
Assignee: Stuart Douglas
Priority: Blocker
If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
The explanation is that the web application uses a filter to compress the content in gzip format.
For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
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:
-------------------------------------------
Is this fixed in undertow? I'm directly using undertow as an embedded server. I tried using the latest version and it does not seem to have fixed in it.
> 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] (WFCORE-161) JMX monitoring is extremely memory inefficient
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-161:
------------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1154868|https://bugzilla.redhat.com/show_bug.cgi?id=1154868] from POST to MODIFIED
> JMX monitoring is extremely memory inefficient
> ----------------------------------------------
>
> Key: WFCORE-161
> URL: https://issues.jboss.org/browse/WFCORE-161
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Koen Janssens
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha11
>
>
> When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created.
> A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class.
> More background on associated forum thread
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-455) Include additional sun.jdk dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-455?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-455:
------------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1172681|https://bugzilla.redhat.com/show_bug.cgi?id=1172681] from POST to MODIFIED
> Include additional sun.jdk dependencies
> ----------------------------------------
>
> Key: WFCORE-455
> URL: https://issues.jboss.org/browse/WFCORE-455
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Affects Versions: 1.0.0.Alpha14
> Reporter: Mustafa Musaji
> Assignee: David Lloyd
>
> Include the following out of the box for sun.jdk module
> - for working with javax.sql.rowset.RowSetProvider
> <path name="com/sun/rowset"/>
> <path name="com/sun/rowset/providers"/>
> - for working with java.lang.invoke.MethodHandleProxies
> <path name="sun/invoke"/>
> This affects EAP customers using CP releases when overlays override changes made in the original module.xml. For sun.jdk classes, the above packages should be included out of the box.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
