[JBoss JIRA] (WFCORE-1023) embed-host-controller doesn't test the parameter value emptiness
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1023?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1023:
-----------------------------------
[~aloubyansky] Would you mind if I assigned this to myself & fixed?
> embed-host-controller doesn't test the parameter value emptiness
> ----------------------------------------------------------------
>
> Key: WFCORE-1023
> URL: https://issues.jboss.org/browse/WFCORE-1023
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.CR5
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> embed-host-controller doesn't test the parameter value emptiness for configuration files
> {noformat}
> [disconnected /] embed-server --server-config=
> Cannot start embedded server: The --server-config (or -c) parameter requires a value.
> [disconnected /] embed-server -c=
> Cannot start embedded server: The --server-config (or -c) parameter requires a value.
> [disconnected /] embed-host-controller --host-config=
> [domain@embedded /]
> [disconnected /] embed-host-controller --domain-config=
> [domain@embedded /]
> [disconnected /] embed-host-controller -c=
> [domain@embedded /]
> {noformat}
> Follow up to WFCORE-933.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBWEB-313) Deadlock in WsRemoteEndpointImplServer.onWritePossible
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/JBWEB-313?page=com.atlassian.jira.plugin.... ]
Aaron Ogburn updated JBWEB-313:
-------------------------------
Attachment: JBWEB-313.patch
> Deadlock in WsRemoteEndpointImplServer.onWritePossible
> ------------------------------------------------------
>
> Key: JBWEB-313
> URL: https://issues.jboss.org/browse/JBWEB-313
> Project: JBoss Web
> Issue Type: Bug
> Affects Versions: JBossWeb-7.5.0.GA
> Environment: JBoss EAP 6.4.5
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-313.patch
>
>
> A deadlock is possible in WsRemoteEndpointImplServer.onWritePossible:
> {code}
> http-/0.0.0.0:8080-1":
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:93)
> - waiting to lock <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer)
> - locked <0x00000006dee6a200> (a java.lang.Object)
> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:243)
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:605)
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350)
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171)
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185)
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:252)
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185)
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121)
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228)
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:232)
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818)
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:939)
> - locked <0x00000006deeeb9c0> (a java.lang.Object)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.apache.tomcat.util.net.NioEndpoint$DefaultThreadFactory$1$1.run(NioEndpoint.java:1249)
> at java.lang.Thread.run(Thread.java:745)
> "EJB default - 1":
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:81)
> - waiting to lock <0x00000006dee6a200> (a java.lang.Object)
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:76)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:444)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:334)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:741)
> - locked <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:239)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:182)
> at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6031) WeldProvider.containerShutDown() not invoked if the deployment fails
by Martin Kouba (JIRA)
Martin Kouba created WFLY-6031:
----------------------------------
Summary: WeldProvider.containerShutDown() not invoked if the deployment fails
Key: WFLY-6031
URL: https://issues.jboss.org/browse/WFLY-6031
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.CR5
Reporter: Martin Kouba
Assignee: Martin Kouba
Fix For: 10.0.0.Final
We've run into this problem when executing Weld and CDI TCK test suites on a specific HP-UX machine. Both test suites contain a lot of scenarios where the deployment fails. HP-UX jvm cannot handle this load and the test suite fails with OutOfMemoryError.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Ståle Pedersen commented on WFCORE-1277:
----------------------------------------
aesh-0.66.3 is out, please give it a try [~soul2zimate]
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Ståle Pedersen
> Priority: Minor
> Fix For: 2.0.8.Final
>
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Ståle Pedersen commented on WFCORE-1277:
----------------------------------------
ill push out a 0.66.3 now, that is working as expected afaik.
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Ståle Pedersen
> Priority: Minor
> Fix For: 2.0.8.Final
>
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1277:
-------------------------------------
Fix Version/s: 2.0.8.Final
[~stalep][~soul2zimate] I'm raising this to Blocker due to the "[disconnected /] [disconnected /]" issue, which happens following common actions like a "shutdown" command. Can you guys update me on the possibility of getting a fix for this, ASAP, even a temporary one? I'd like this fixed in WildFly 10.0.0.Final.
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Ståle Pedersen
> Priority: Minor
> Fix For: 2.0.8.Final
>
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5081) WebSphere MQ 8 RA - [TCK] - Defining connection factory by @JMSConnectionFactoryDefinition annotation or in deployment descriptor fails
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5081?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5081:
-----------------------------------
I had a look at this issue and it will required some additional development.
First, note that there is no relation between the default resource adapter for MDB in ejb subsystem and these annotations.
If the resourceAdapter of the JMSConnectionFactoryDefinition is not specified, this will use the "default behaviour" which is to create a pooled-connection-factory from the messaging-activemq subsystem (the default resource adapter for MDB is not related).
If the resourceAdapter is defined, we could instead delegate to the connectors subsystem that is able to handle the more generic @ConnectionFactory definition.
In any case, the TCK tests will not pass without modifying the annotations to set the resourceAdapter property to "wmq.jmsra" or something similar.
> WebSphere MQ 8 RA - [TCK] - Defining connection factory by @JMSConnectionFactoryDefinition annotation or in deployment descriptor fails
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5081
> URL: https://issues.jboss.org/browse/WFLY-5081
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Beta1
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
>
> If WebSphere MQ 8 resource adapter is configured as default resource adapter for MDB in ejb subsystem and MDB is trying to deploy its connection factory like:
> {code}
> @JMSConnectionFactoryDefinition(
> description="Define TopicConnectionFactory AppClientMyTestTopicConnectionFactory",
> interfaceName="javax.jms.TopicConnectionFactory",
> name="java:module/AppClientMyTestTopicConnectionFactory",
> user = "j2ee",
> password = "j2ee",
> )
> {code}
> then deployment fails with:
> {code}
> 11:18:37,471 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0001: Content added at location /home/mnovak/mnovak_home/tmp/tck7/work/jboss-eap-7.0/standalone/data/content/1d/4fbecb4dd1e3a9c03b791cd64c21cd6b7f49de/content
> 11:18:37,475 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "mdb-1.0-SNAPSHOT.jar" (runtime-name: "mdb-1.0-SNAPSHOT.jar")
> 11:18:37,499 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0042: Started message driven bean 'SampleMdb' with 'wmq.jmsra' resource adapter
> 11:18:37,501 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "mdb-1.0-SNAPSHOT.jar")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.app.\"mdb-1.0-SNAPSHOT\".AppClientMyTestQueueConnectionFactory is missing [jboss.connection-factory.reference-factory.jboss.naming.context.java.app.\"mdb-1.0-SNAPSHOT\".AppClientMyTestQueueConnectionFactory]"]}
> 11:18:37,616 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "mdb-1.0-SNAPSHOT.jar" (runtime-name : "mdb-1.0-SNAPSHOT.jar")
> 11:18:37,616 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0185: Newly corrected services:
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.CREATE (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.JndiBindingsService (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.START (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.VIEW.SampleMdb.MESSAGE_ENDPOINT (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.ejb.non-functional-timerservice (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".jndiDependencyService (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".moduleDeploymentRuntimeInformation (new available)
> service jboss.naming.context.java.app."mdb-1.0-SNAPSHOT".AppClientMyTestQueueConnectionFactory (new available)
> service jboss.naming.context.java.app."mdb-1.0-SNAPSHOT".env (new available)
> service jboss.naming.context.java.comp."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".SampleMdb (new available)
> service jboss.naming.context.java.comp."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".SampleMdb.TransactionSynchronizationRegistry (new available)
> service jboss.naming.context.java.comp."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".SampleMdb.UserTransaction (new available)
> service jboss.naming.context.java.module."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".env (new available)
> {code}
> Customer impact:
> Any deployment which needs to define its connection factory in deployment will fail. Customer cannot use @JMSConnectionFactoryDefinition to deploy connection factory.
> Debugging showed that deployment of connection factory defined in @JMSConnectionFactoryDefinition is using messaging activemq extension integration. WebSphereMQ's managed connection factory cannot be added as pooled-connection-factory to messaging-activemq subsystem.
> We need to provide a way 3rd party JMS managed connection factory will be created and registered to JNDI.
> Failing TCK tests failing because of this issue:
> {code}
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> {cdde}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JBWEB-313) Deadlock in WsRemoteEndpointImplServer.onWritePossible
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-313?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-313:
-----------------------------------------------
Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1299057|https://bugzilla.redhat.com/show_bug.cgi?id=1299057] from NEW to ASSIGNED
> Deadlock in WsRemoteEndpointImplServer.onWritePossible
> ------------------------------------------------------
>
> Key: JBWEB-313
> URL: https://issues.jboss.org/browse/JBWEB-313
> Project: JBoss Web
> Issue Type: Bug
> Affects Versions: JBossWeb-7.5.0.GA
> Environment: JBoss EAP 6.4.5
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
>
> A deadlock is possible in WsRemoteEndpointImplServer.onWritePossible:
> {code}
> http-/0.0.0.0:8080-1":
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:93)
> - waiting to lock <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer)
> - locked <0x00000006dee6a200> (a java.lang.Object)
> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:243)
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:605)
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350)
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171)
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185)
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:252)
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185)
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121)
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228)
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:232)
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818)
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:939)
> - locked <0x00000006deeeb9c0> (a java.lang.Object)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.apache.tomcat.util.net.NioEndpoint$DefaultThreadFactory$1$1.run(NioEndpoint.java:1249)
> at java.lang.Thread.run(Thread.java:745)
> "EJB default - 1":
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:81)
> - waiting to lock <0x00000006dee6a200> (a java.lang.Object)
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:76)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:444)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:334)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$TextMessageSendHandler.write(WsRemoteEndpointImplBase.java:741)
> - locked <0x00000006dee6a1a8> (a java.nio.HeapByteBuffer)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:239)
> at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:182)
> at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months