[JBoss JIRA] (JBMESSAGING-1962) javax.jms.JMSException: Failed to route Reference[6147840512252321]:RELIABLE to dmEventTopic
by Tony Fan (JIRA)
Tony Fan created JBMESSAGING-1962:
-------------------------------------
Summary: javax.jms.JMSException: Failed to route Reference[6147840512252321]:RELIABLE to dmEventTopic
Key: JBMESSAGING-1962
URL: https://issues.jboss.org/browse/JBMESSAGING-1962
Project: JBoss Messaging
Issue Type: Release
Components: Messaging Core
Affects Versions: 1.4.8.SP9
Reporter: Tony Fan
System running for couple days then we see following error from server.log:
017-07-24 19:07:05,093 ERROR [com.ilrd.gem.plaf.dm.util.DmMessageSender] Caught MessageSenderException while attempting to send value object message
com.ilrd.gem.plaf.dm.messaging.MessageSenderException: Unable to send message.
at com.ilrd.gem.plaf.dm.messaging.JmsMessageSender.sendMessage(JmsMessageSender.java:238)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.doSendValueObjectMessage(DmMessageSender.java:290)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.sendMessageFromQueue(DmMessageSender.java:256)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.processMessageQueue(DmMessageSender.java:237)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.access$000(DmMessageSender.java:35)
at com.ilrd.gem.plaf.dm.util.DmMessageSender$1.run(DmMessageSender.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.jms.JMSException: Failed to route Reference[6147840512252321]:RELIABLE to dmEventTopic
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:791)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:437)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:162)
at sun.reflect.GeneratedMethodAccessor365.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:2084)
at org.jboss.remoting.Client.invoke(Client.java:879)
at org.jboss.remoting.Client.invoke(Client.java:867)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:499)
at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeTarget(ClientSessionDelegate$send_6145266547759487588.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:694)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleSend_16166428.invoke(SessionAspect_z_handleSend_16166428.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:276)
at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect_z_handleSend_16166428.invoke(ProducerAspect_z_handleSend_16166428.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:165)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:208)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:146)
at com.ilrd.gem.plaf.dm.messaging.JmsMessageSender.sendMessage(JmsMessageSender.java:203)
... 6 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-12346 to WFCORE-3103:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3103 (was: JBEAP-12346)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Modules
(was: CLI)
(was: Modules)
Affects Version/s: (was: 7.1.0.ER2)
> Embedded server doesn't close open file handles
> -----------------------------------------------
>
> Key: WFCORE-3103
> URL: https://issues.jboss.org/browse/WFCORE-3103
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Jan Blizňák
> Assignee: Brian Stansberry
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped.
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3102) Implement the LocalClient close
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-3102:
-----------------------------------------
Summary: Implement the LocalClient close
Key: WFCORE-3102
URL: https://issues.jboss.org/browse/WFCORE-3102
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 3.0.0.Beta28
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
Closing the LocalClient does nothing currently. It should interrupt all the operations it is executing
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: 3.0.0.Beta29
(was: 3.0.0.CR1)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 3.0.0.Beta29
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2193) JmxControlledStateNotificationsTestCase fails with security manager in WF core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2193?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-2193.
--------------------------------------
Resolution: Done
[~jtymel] I'm re-resolving this is it appears there is a separate (resolved) issue about IBM. If there is still a problem, please open a new JIRA, Please only reopen this if the originally reported failure pattern is still there.
> JmxControlledStateNotificationsTestCase fails with security manager in WF core
> ------------------------------------------------------------------------------
>
> Key: WFCORE-2193
> URL: https://issues.jboss.org/browse/WFCORE-2193
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Environment: IBM JDK
> Reporter: Jan Tymel
> Assignee: Ingo Weiss
> Fix For: 3.0.0.Alpha23
>
>
> *org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase*
> {{cd testsuite/domain/}}
> {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}}
> *org.wildfly.core.test.standalone.mgmt.events.JmxControlledStateNotificationsTestCase*
> {{cd testsuite/manualmode/}}
> {{mvn test -DtestLogToFile=false -Dtest=JmxControlledStateNotificationsTestCase -Dsecurity.manager}}
> Both test cases fail with:
> {code}
> Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE! - in org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase
> org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.007 sec <<< FAILURE!
> java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar <no signer certificates>)\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar <no signer certificates>)\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"test.deployment.jmx" => "org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar <no signer certificates>)\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.util.PropertyPermission\" \"user.dir\" \"read\")\" in code source \"(vfs:/content/test-jmx-notifications-deployment.jar <no signer certificates>)\" of \"ModuleClassLoader for Module \"deployment.test-jmx-notifications-deployment.jar:main\" from Service Module Loader\")"},"WFLYCTL0412: Required services that are not installed:" => ["test.deployment.jmx"],"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},"rolled-back" => true}}}}}}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115)
> at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100)
> at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.setup(JMXFacadeListenerDeploymentSetupTask.java:75)
> at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.setupDomain(JmxControlledStateNotificationsTestCase.java:66)
> org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase Time elapsed: 0.014 sec <<< FAILURE!
> java.lang.AssertionError: {"outcome" => "failed","result" => undefined,"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"main-one" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found"}}}}}},"rolled-back" => true,"server-groups" => {"main-server-group" => {"host" => {"master" => {"main-one" => {"response" => {"outcome" => "failed","failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test-jmx-notifications-deployment.jar\")]' not found","rolled-back" => true}}}}}}}
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.integration.management.rbac.RbacUtil.checkOperationResult(RbacUtil.java:115)
> at org.jboss.as.test.integration.management.rbac.RbacUtil.executeOperation(RbacUtil.java:100)
> at org.wildfly.test.jmx.JMXFacadeListenerDeploymentSetupTask.tearDown(JMXFacadeListenerDeploymentSetupTask.java:115)
> at org.jboss.as.test.integration.domain.events.JmxControlledStateNotificationsTestCase.tearDownDomain(JmxControlledStateNotificationsTestCase.java:71)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: 3.0.0.CR1
(was: 4.0.0.Alpha1)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
> Fix For: 3.0.0.CR1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1309) Channel binding callback cannot support tls-unique
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1309?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1309:
----------------------------------
Fix Version/s: 1.1.0.CR4
> Channel binding callback cannot support tls-unique
> --------------------------------------------------
>
> Key: ELY-1309
> URL: https://issues.jboss.org/browse/ELY-1309
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI, Authentication Client, Authentication Server, Callbacks, SASL
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 1.1.0.CR4
>
>
> The revised API for the channel binding callback uses SSL sessions, but the standard TLS channel binding types [according to the RFC|https://tools.ietf.org/html/rfc5929] are associated with the connection, not the session. It is likely that the proposed channel bindings JDK API will exist on SSLSocket/SSLEngine. Introduce an API that allows the callback handlers to acquire the connection information using a forward-compatible API.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2732) Elytron - it should also be possible to store OTP algorithm on security realm level
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2732?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2732:
-------------------------------------
Priority: Major (was: Critical)
> Elytron - it should also be possible to store OTP algorithm on security realm level
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2732
> URL: https://issues.jboss.org/browse/WFCORE-2732
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Yeray Borges
>
> It should be possible to store OTP algorithm name on security realm level too.
> Using of the OTP SASL mechanism requires modifiable realm and currently only ldap-realm integration is finished.
> The ldap-realm now requires to store the algorithm name into an LDAP attribute together with the rest of OTP configuration (seed, hash, sequence), but this can be limiting (or space vasting) when the algorithm is the same for all users in the realm. There should be a possibility to configure the OTP algorithm name also on the realm level and share it for users. Make it an alternative for {{ldap-realm.identity-mapping.otp-credential-mapper.algorithm-from}} configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months