[JBoss JIRA] (WFLY-6480) JNDIBindingMBeanTestCase misses JndiPermission when run with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6480?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reopened WFLY-6480:
---------------------------------
> JNDIBindingMBeanTestCase misses JndiPermission when run with security manager
> -----------------------------------------------------------------------------
>
> Key: WFLY-6480
> URL: https://issues.jboss.org/browse/WFLY-6480
> Project: WildFly
> Issue Type: Bug
> Reporter: Jan Tymel
> Assignee: Ivo Studensky
> Fix For: 10.1.0.CR1
>
>
> *JNDIBindingMBeanTestCase*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.sar.JNDIBindingMBeanTestCase -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.naming.java.permission.JndiPermission" "global/env/foo/legacy2" "bind")" in code source "(vfs:/content/multiple-jndi-binding-mbeans.sar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.jboss.as.naming.NamingContext.check(NamingContext.java:591)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:251)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:264)
> at org.jboss.as.naming.NamingContext.bind(NamingContext.java:289)
> at javax.naming.InitialContext.bind(InitialContext.java:425)
> at javax.naming.InitialContext.bind(InitialContext.java:425)
> at org.jboss.as.test.integration.sar.JNDIBindingService.start(JNDIBindingService.java:53)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1673) Testsuite: tests for CLI controller aliases
by Martin Schvarcbacher (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1673?page=com.atlassian.jira.plugi... ]
Martin Schvarcbacher updated WFCORE-1673:
-----------------------------------------
Description:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
+*TEST PLAN for controller aliases*+
# set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
# connect to controller alias with all options (protocol, hostname, port) specified
# protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
# empty jboss-cli.xml configuration uses implicit settings for both default controller and controller alias
*+TEST PLAN for use-legacy-override+*
{code:shell}
./bin/jboss-cli.[sh/bat] --connect [--controller=localhost:$TESTED_PORT]
{code}
* <default-protocol use-legacy-override=true> && no protocol specified && port=9999 → use remoting://
* <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
* no protocol specified in <default-controller> → use <default-protocol>
* <default-protocol> is overridden by protocol defined in <default-controller> (JBEAP 7.0.0 new element)
was:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
+*TEST PLAN*+
# set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
# connect to controller alias with all options (protocol, hostname, port) specified
# protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
> Testsuite: tests for CLI controller aliases
> -------------------------------------------
>
> Key: WFCORE-1673
> URL: https://issues.jboss.org/browse/WFCORE-1673
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: Martin Schvarcbacher
> Assignee: Martin Schvarcbacher
> Priority: Minor
>
> Added integration tests for server aliases defined in jboss-cli.xml
> Usage in bin/jboss-cli.xml:
> {code:xml}
> <controllers>
> <controller name="ServerOne">
> <protocol>http-remoting</protocol>
> <host>localhost</host>
> <port>9990</port>
> </controller>
> </controllers>
> {code}
> {code:bash}
> ./bin/jboss-cli.sh --controller=ServerOne --connect
> {code}
> +*TEST PLAN for controller aliases*+
> # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
> # connect to controller alias with all options (protocol, hostname, port) specified
> # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
> # empty jboss-cli.xml configuration uses implicit settings for both default controller and controller alias
> *+TEST PLAN for use-legacy-override+*
> {code:shell}
> ./bin/jboss-cli.[sh/bat] --connect [--controller=localhost:$TESTED_PORT]
> {code}
> * <default-protocol use-legacy-override=true> && no protocol specified && port=9999 → use remoting://
> * <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
> * no protocol specified in <default-controller> → use <default-protocol>
> * <default-protocol> is overridden by protocol defined in <default-controller> (JBEAP 7.0.0 new element)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFBUILD-14) Conflicting feature pack dependency versions should not be allowed
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-14?page=com.atlassian.jira.plugin... ]
Thomas Diesler closed WFBUILD-14.
---------------------------------
Resolution: Won't Fix
[10:24 AM] Thomas Diesler: My dep chain is wildfly-camel => fuse-patch + wildlfy, fuse-patch => wildfly. The versions of wildfly may be different. What should happen?
[10:24 AM] Thomas Diesler: The obvious thing to happen is an error, right?
[10:26 AM] Stuart Douglas: yes
[10:26 AM] Thomas Diesler: Another option is that the higher version of wildfly is used, if both are version compatible
[10:26 AM] Stuart Douglas: we don't know what is compatible
[10:26 AM] Stuart Douglas: error is the only this that really makes sense
[10:26 AM] Stuart Douglas: @AlexeyLoubyansky is actually working on version two of this
[10:27 AM] Stuart Douglas: so it is unlikely that there is going to be any big changes in the current code base
[10:27 AM] Thomas Diesler: Yep, I would agree. In that case this issue is reduced to a "does not fail" thing, which can be resolved as "won't fix"
https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/s...
> Conflicting feature pack dependency versions should not be allowed
> ------------------------------------------------------------------
>
> Key: WFBUILD-14
> URL: https://issues.jboss.org/browse/WFBUILD-14
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: James Netherton
> Assignee: Stuart Douglas
> Fix For: 1.1.7.Final
>
>
> There was a brief discussion about this on the WildFly dev mailing list so I'm capturing the problem here as well.
> Consider the following.
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
> {code}
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:
> {code:xml}
> <dependencies>
> <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> <artifact name="org.foo:feature-pack-A" />
> </dependencies>
> {code}
> The result is that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions
> At the moment the plugins allow this scenario, which can lead to all sorts of horrors when using the server-provisioning plugin to provision an app server.
> CrossRef: https://github.com/wildfly-extras/fuse-patch/issues/101
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (DROOLS-1243) ClassCastException at runtime when trying to match "from" and a built-in accumulate function.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1243?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1243:
-------------------------------------
Also this commit is necessary https://github.com/droolsjbpm/drools/commit/049a67a78
> ClassCastException at runtime when trying to match "from" and a built-in accumulate function.
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-1243
> URL: https://issues.jboss.org/browse/DROOLS-1243
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
>
> A rule like this
> {code:java}
> global java.util.List list;
> rule R when
> $theFrom : Double() from accumulate(MyPerson( $val : age );
> sum( $val ) )
> then
> list.add($theFrom);
> end
> {code}
> works fine but if modified like:
> {code:java}
> import java.math.BigDecimal;
> global java.util.List list;
> rule R when
> $theFrom : BigDecimal() from accumulate(MyPerson( $val : age );
> sum( $val ) )
> then
> list.add($theFrom);
> end
> {code}
> then it breaks at runtime, with {{ClassCastException}}.
> Suggested correct behavior:
> {quote}it should either raise a compilation error (if it is a typed function, like sum()) or just fail to match at runtime, as BigDecimal() does not match the result of sum(){quote}
> full stack trace for reference:
> {code:java}
> Exception executing consequence for rule "R" in defaultpkg: java.lang.ClassCastException: java.lang.Double cannot be cast to java.math.BigDecimal
> at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1110)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1360)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1298)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1344)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1325)
> at org.drools.compiler.integrationtests.AccumulateTest.testCCEAtRuntimeFromAccumulate(AccumulateTest.java:3116)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.ClassCastException: java.lang.Double cannot be cast to java.math.BigDecimal
> at defaultpkg.Rule_R880096074DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at defaultpkg.Rule_R880096074DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1099)
> ... 32 more
> {code}
> Will submit test case for reproducing the error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6914) Description of binding-type for rebind operation should not include external-context type
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6914?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-5517 to WFLY-6914:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6914 (was: JBEAP-5517)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Naming
(was: Naming)
Affects Version/s: (was: 7.1.0.DR1)
> Description of binding-type for rebind operation should not include external-context type
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6914
> URL: https://issues.jboss.org/browse/WFLY-6914
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Minor
>
> naming/src/main/resources/org/jboss/as/naming/subsystem/LocalDescriptions.properties:
> {code}
> binding.rebind.binding-type=The type of binding to create, may be simple, lookup, external-context or object-factory
> {code}
> The {{external-context}} binding cannot be used for {{rebind}} operation. I'd suggest removing it from the operation description.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6913) RebindTestCase does not remove all created bindings
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6913?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved JBEAP-5516 to WFLY-6913:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6913 (was: JBEAP-5516)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Naming
(was: Naming)
Affects Version/s: (was: 7.1.0.DR1)
> RebindTestCase does not remove all created bindings
> ---------------------------------------------------
>
> Key: WFLY-6913
> URL: https://issues.jboss.org/browse/WFLY-6913
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> {{org.jboss.as.test.integration.naming.RebindTestCase}} creates 2 bindings but removes only one of them at the end of the test. I'd suggest removing all created bindings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1668) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1668?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1668:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1358556
Bugzilla Update: Perform
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1668
> URL: https://issues.jboss.org/browse/WFCORE-1668
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 3.0.0.Alpha4
>
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6898) ConcurrentModificationException when returning from JMS onMessage() MBean
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6898?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6898:
------------------------------------
Stuart is right. It seems that the only way to get this exception is to create a new request scoped bean during {{@PreDestroy}}. Even the modification to the original {{InvocationContext}} should not matter at this point of deactivation.
One way to get more info without reproducer is to enable TRACE logging for {{org.jboss.weld.Context}} category (see also http://weld.cdi-spec.org/documentation/#7):
{code:xml}
<console-handler name="CONSOLE">
<level name="INFO"/> <!-- REMOVE THIS -->
</console-handler>
...
<logger category="org.jboss.weld.Context">
<level name="TRACE"/>
</logger>
{code}
> ConcurrentModificationException when returning from JMS onMessage() MBean
> -------------------------------------------------------------------------
>
> Key: WFLY-6898
> URL: https://issues.jboss.org/browse/WFLY-6898
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.CR1
> Reporter: Harold Campbell
> Assignee: Stuart Douglas
>
> I receive the following stacktrace when an MBean's onMessage() returns. The transaction is rolled back and the message marked as undelivered. This started sometime after nightly #2280 which works fine for me.
> 2016-07-30 21:51:49,273 TRACE [com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener] (Thread-0 (ActiveMQ-client-global-threads-556320704)) Finished processing run 16819
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$view3.onMessage(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$endpoint1.onMessage(Unknown Source)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:310)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1018)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:48)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1145)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:160)
> at org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:58)
> at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
> at org.jboss.weld.context.ejb.EjbRequestContextImpl.deactivate(EjbRequestContextImpl.java:47)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:76)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6912) Socket leak when client doesn't read the entire response
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6912?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6912.
----------------------------------
Resolution: Out of Date
There have been a lot of fixes in this area, 8.2 is quite an old version. Please re-open if you can reproduce on WF10.
> Socket leak when client doesn't read the entire response
> --------------------------------------------------------
>
> Key: WFLY-6912
> URL: https://issues.jboss.org/browse/WFLY-6912
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Cent OS 6.7/7.1
> Reporter: Sandeep Krishnan
> Assignee: Stuart Douglas
> Labels: undertow, wildfly
>
> I'm facing an issue similar to UNDERTOW-427. If the client doesn't read the entire response sent by the server and terminates the connection before server does, then there is socket leak.
> Open files count
> =============
> [root@xyz apps]# lsof -p <jboss-pid> | wc -l
> 1331
> [root@xyz apps]# lsof | wc -l
> 12049
> After running around 1.5 k times.
> =========================
> [root@xyz apps]# lsof -p <jboss-pid> | grep "can't identify pro" | wc -l
> 1539
> [root@xyz apps]# lsof -p <jboss-pid> | wc -l
> 2998
> [root@xyz apps]# lsof | wc -l
> 14831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6912) Socket leak when client doesn't read the entire response
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6912?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6912:
--------------------------------------
Is this still an issue in Wildfly 10?
> Socket leak when client doesn't read the entire response
> --------------------------------------------------------
>
> Key: WFLY-6912
> URL: https://issues.jboss.org/browse/WFLY-6912
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Cent OS 6.7/7.1
> Reporter: Sandeep Krishnan
> Assignee: Stuart Douglas
> Labels: undertow, wildfly
>
> I'm facing an issue similar to UNDERTOW-427. If the client doesn't read the entire response sent by the server and terminates the connection before server does, then there is socket leak.
> Open files count
> =============
> [root@xyz apps]# lsof -p <jboss-pid> | wc -l
> 1331
> [root@xyz apps]# lsof | wc -l
> 12049
> After running around 1.5 k times.
> =========================
> [root@xyz apps]# lsof -p <jboss-pid> | grep "can't identify pro" | wc -l
> 1539
> [root@xyz apps]# lsof -p <jboss-pid> | wc -l
> 2998
> [root@xyz apps]# lsof | wc -l
> 14831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months