[JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin... ]
Chao Wang reassigned WFCORE-227:
--------------------------------
Assignee: Chao Wang (was: David Lloyd)
> RejectedExecutionException when closing ModelControllerClient client
> --------------------------------------------------------------------
>
> Key: WFCORE-227
> URL: https://issues.jboss.org/browse/WFCORE-227
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 1.0.0.Alpha11
> Reporter: Alessio Soldano
> Assignee: Chao Wang
> Fix For: 1.0.0.Alpha15
>
>
> After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite:
> {noformat}
> Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3@5651c0c2 rejected from org.xnio.XnioWorker$TaskPool@11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
> at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> 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)
> {noformat}
> The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method.
> The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin... ]
Chao Wang reassigned WFCORE-227:
--------------------------------
Assignee: David Lloyd (was: Chao Wang)
> RejectedExecutionException when closing ModelControllerClient client
> --------------------------------------------------------------------
>
> Key: WFCORE-227
> URL: https://issues.jboss.org/browse/WFCORE-227
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 1.0.0.Alpha11
> Reporter: Alessio Soldano
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha15
>
>
> After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite:
> {noformat}
> Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3@5651c0c2 rejected from org.xnio.XnioWorker$TaskPool@11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
> at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> 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)
> {noformat}
> The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method.
> The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1907:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1187193|https://bugzilla.redhat.com/show_bug.cgi?id=1187193] from POST to MODIFIED
> ENCRYPT: asymmetric encryption fails on merge
> ---------------------------------------------
>
> Key: JGRP-1907
> URL: https://issues.jboss.org/browse/JGRP-1907
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.2
>
> Attachments: encrypt.xml, EncryptKeyStore.xml
>
>
> {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption.
> To reproduce:
> * Members A and B
> * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}}
> * Form cluster {{(A,B)}}
> * Create a network split: {{(A)}} and {{(B)}}
> * Remove the network split
> * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}}
> * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works.
> * Symmetric encryption: {{EncryptKeyStore.xml}}
> * Asymmetric encryption: {{encrypt.xml}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-3786) Validator interceptor does not work in 8.1 on EJBs
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3786?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3786.
----------------------------------
Fix Version/s: 8.2.0.Final
Resolution: Done
> Validator interceptor does not work in 8.1 on EJBs
> --------------------------------------------------
>
> Key: WFLY-3786
> URL: https://issues.jboss.org/browse/WFLY-3786
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: John Ament
> Assignee: Jason Greene
> Fix For: 8.2.0.Final
>
>
> Take a look at the following git repo
> https://github.com/johnament/hornetq-jms-issue
> Run the test ValidationTest. When you execute, you'll see the following error:
> Caused by: org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.weld.exceptions.IllegalArgumentException : WELD-001456: Argument bean must not be null [Proxied because : Original exception caused: class java.lang.ClassNotFoundException: org.jboss.weld.exceptions.IllegalArgumentException]
> Looking at it at first, you might think it's the result of validation execution (since the bean's @notNull). What's actually happening is the interceptor is trying to get a reference to the validator and failing, hence the "argument bean must not be null" part.
> It seems like the validation extension doesn't get activated properly when I'm dealing with a JAR within a WAR file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4397) WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4397?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4397:
--------------------------------------
I just tried this out and can't reproduce it. Can you share the jmeter script you are using?
> WildFly.8.1.0.Final's Asynchronous servlets cause connection leak
> -----------------------------------------------------------------
>
> Key: WFLY-4397
> URL: https://issues.jboss.org/browse/WFLY-4397
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Alpha1
> Environment: Java(TM) SE Runtime Environment (build 1.7.0_25)
> Reporter: Wind Wild
> Assignee: Stuart Douglas
>
> Recently, I used Asynchronous servlets and AsyncListeners on my project.But when it runs on WildFly.8.1.0.Final,a problem appeared as following:
>
> 2015-01-10 10:08:40,936 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015004: Caught exception writing deployment marker file /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying: java.io.FileNotFoundException: /opt/jboss/standalone/deployments/OpenESBHttp_full_prd.war.isundeploying (Too many open files)
> at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:212) [rt.jar:1.7.0_25]
> at java.io.FileOutputStream.<init>(FileOutputStream.java:165) [rt.jar:1.7.0_25]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.createMarkerFile(FileSystemDeploymentService.java:984) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.access$2800(FileSystemDeploymentService.java:83) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScannerTask.recordInProgress(FileSystemDeploymentService.java:1044) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:431) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:147) [wildfly-deployment-scanner-8.1.0.Final.jar:8.1.0.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
>
> 2015-01-10 10:08:41,329 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017535: Unregistered web context: /ServiceWeb
> 2015-01-10 10:08:41,481 INFO [net.sf.json.xml.XMLSerializer] (HttpServiceHandler-50543) Using default type string
> 2015-01-10 10:08:42,225 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-3)
> 2015-01-10 10:08:43,504 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment OpenESBHttp_full_prd.war (runtime-name: OpenESBHttp_full_prd.war) in 2373ms
>
> From this server log,we can see that there is "Too open many files" problem.and on the WildFly‘s manager console,we can see that my project was undeployed.When i used command "lsof -p pid | wc -l" to find the count of open file-hander, 50000 open file,because there were a lot of "can't identify protocol" as following:
> java 25625 jbossuser 460u sock 0,6 0t0 62184686 can't identify protocol
> java 25625 jbossuser 461u sock 0,6 0t0 62170175 can't identify protocol
> java 25625 jbossuser 462u sock 0,6 0t0 62159509 can't identify protocol
> java 25625 jbossuser 463u sock 0,6 0t0 62193366 can't identify protocol
> java 25625 jbossuser 464u sock 0,6 0t0 62181816 can't identify protocol
> java 25625 jbossuser 465u sock 0,6 0t0 62159028 can't identify protocol
> java 25625 jbossuser 466u sock 0,6 0t0 62181150 can't identify protocol
> java 25625 jbossuser 467u sock 0,6 0t0 62165298 can't identify protocol
> java 25625 jbossuser 468u sock 0,6 0t0 62181859 can't identify protocol
> java 25625 jbossuser 469u sock 0,6 0t0 62155350 can't identify protocol
> java 25625 jbossuser 470u sock 0,6 0t0 62184687 can't identify protocol
> java 25625 jbossuser 471u sock 0,6 0t0 62150063 can't identify protocol
> java 25625 jbossuser 472u IPv4 70228479 0t0 TCP lesbprdapp16:webcache->192.168.53.177:23420 (ESTABLISHED)
>
> So i know there maybe occur connection leak on WildFly, and i made a test as follow:
> I use apache's jmeter to test this project,i use 50 users to request it,then use "lsof -p pid | can't identify protocol | wc -l" to find is there have “can't identify protocol”,the number is 0.But when i stop the request,there appeared lots of "can't identify protocol",the same phenomenon appeared on wildfly-9.0.0.Alpha1 and wildfly-8.2.0.Final but not appeared on tomcat.So i'm doubt that this is wildfly's bug,Is there anyony encounter this problem and tell me how to solve it.
>
> Moreover, i found a issue is like above problem:
> [WFLY-3652] Network connection leak - JBoss Issue Tracker
>
> but don't think they are the same probem,because it say the problem alrendy was fixed in wildfly-9.0.0.Alpha1,but above problem wasn't fixed when i test my project on wildfly-9.0.0.Alpha1.
>
> Who can help me solve this problem? thanks!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4402:
--------------------------------------
Just use 'availability-service.war' as the runtime name instead of 'availability-service'
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war, Screen Shot 2015-03-03 at 11.03.45 PM.png
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Abhijit Sarkar commented on WFLY-4402:
--------------------------------------
[~swd847] How do you customize the context root then? Using a jboss-* DD?
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war, Screen Shot 2015-03-03 at 11.03.45 PM.png
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-4402.
--------------------------------
Resolution: Rejected
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war, Screen Shot 2015-03-03 at 11.03.45 PM.png
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4402:
--------------------------------------
You need the .war on the end of the runtime name, otherwise the deployment code does not detect that it is a war, and you won't be able to load classes from WEB-INF/classes and WEB-INF/lib (also, it just plain old won't work because no web context will be created).
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war, Screen Shot 2015-03-03 at 11.03.45 PM.png
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months