[JBoss JIRA] (WFLY-5931) HTTP connection is getting closed after 5 mins
by Rakesh Kumar (JIRA)
Rakesh Kumar created WFLY-5931:
----------------------------------
Summary: HTTP connection is getting closed after 5 mins
Key: WFLY-5931
URL: https://issues.jboss.org/browse/WFLY-5931
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 9.0.2.Final
Environment: Wildfly 9.0.1 + Linux
Reporter: Rakesh Kumar
Assignee: Stuart Douglas
Priority: Critical
Fix For: 9.x.x TBD
HTTP connection is getting closed after 5 mins with Linux + Wildfly 9.0.1 and throws broken pipe exception after the request is processed, It works fine in windows + Wildfly 9.0.1.
I tried to increase keepalive timeout using the following alternatives.
• Update values in httpd.conf from 300 seconds to 1500 seconds
• Add KeepAliveTimeout response header in standalone.xml
• Add header in response using “response.addHeader("Keep-Alive", "timeout=180000");”
• Updated jsp to add ("Keep-Alive", "timeout=180000" ) in response header.
None of the above alternatives worked.
Error message :
2015-10-23 18:46:47,250 ERROR [default task-29] [RequestServlet] Unknown exception detected: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) [rt.jar:1.7.0_45]
at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) [rt.jar:1.7.0_45]
at sun.nio.ch.IOUtil.write(IOUtil.java:148) [rt.jar:1.7.0_45]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5930) Unable to load deployments
by Hamed Abdollahpour (JIRA)
Hamed Abdollahpour created WFLY-5930:
----------------------------------------
Summary: Unable to load deployments
Key: WFLY-5930
URL: https://issues.jboss.org/browse/WFLY-5930
Project: WildFly
Issue Type: Feature Request
Components: Web Console
Affects Versions: 9.0.2.Final
Reporter: Hamed Abdollahpour
Assignee: Heiko Braun
Fail to get list of deployment on application server with this error:
12:19:40,130 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "discripto-ear.ear"),
("subdeployment" => "discripto-rest.war"),
("subsystem" => "undertow"),
("servlet" => "com.wpic.discripto.rest.App")
]): java.lang.NullPointerException
at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
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)
12:21:20,258 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "discripto-ear.ear"),
("subdeployment" => "discripto-rest.war"),
("subsystem" => "undertow"),
("servlet" => "com.wpic.discripto.rest.App")
]): java.lang.NullPointerException
at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
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)
It works perfect after restarting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5922:
--------------------------------------
Actually it looks like this is then re-exported from javax/ejb/api
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5922:
--------------------------------------
Otherwise you also need to exclude org.omg.api, as it re-exports classes from the javax.orb.api module.
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5922:
--------------------------------------
Have you added the exclusions to both?
A simpler way it to just exclude the iiop subsystem entirely using exclude-subsystem, which should stop the dependency being added.
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-4296:
------------------------------------
Please write up a migration wiki like document, with links to the documentation for the previous method and the new method (these documents should enumerate all features available).
Please also post here so others looking for it can reference it before then making a comment.
I don't see a problem myself with adding datasources view CLI console, as it looks like there is support to interrogate the current config, then add new config, then reload.
> remove _ds.xml deployment support
> ---------------------------------
>
> Key: WFLY-4296
> URL: https://issues.jboss.org/browse/WFLY-4296
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Stefano Maestri
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-4790) Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4790?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4790:
--------------------------------------
This was fixed by f4bc04646af5bb55f841384d91075f66279e9fb2 in Undertow, however as it involved some (minor) API changes it was not back ported to 1.2.x
> Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
> -------------------------------------------------------------------------------------
>
> Key: WFLY-4790
> URL: https://issues.jboss.org/browse/WFLY-4790
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Alpha6
>
>
> When sending fragmented binary message (message with message payload of length 4 * 2**20 (4M). Sent out in fragments of 64). The server throws {{java.lang.OutOfMemoryError: Direct buffer memory}} [1]
> The memory for direct buffer by default depends on the size set by -Xmx, which is in EAP 7.0.0.DR4 by default set to -Xmx512m. Increasing it just increases the time before the limit is hit (it is enough to send those messages multiple times to hit the limit again).
> I believe the issue is similar to the one for EAP 6.4: [https://bugzilla.redhat.com/show_bug.cgi?id=1223708]
> [1]
> {noformat}
> 15:10:55,463 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658)
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:106)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:97)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:264)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months