[JBoss JIRA] (WFLY-8713) ISPN000136: Error executing command PutKeyValueCommand, writing keys
by Divey Gupta (JIRA)
Divey Gupta created WFLY-8713:
---------------------------------
Summary: ISPN000136: Error executing command PutKeyValueCommand, writing keys
Key: WFLY-8713
URL: https://issues.jboss.org/browse/WFLY-8713
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Environment: Linux
Reporter: Divey Gupta
Assignee: Jason Greene
We have a cluster of 6 wildfly all running 10.0.0. There was a network blip for few minutes so the connectivity between the members of the cluster got affected.
After that one of the members started throwing the following error on login.
ERROR [InvocationContextInterceptor] (default task-51) ISPN000136: Error executing command PutKeyValueCommand, writing keys [SessionCreationMetaDataKey(k1XmyfLfE8KInACteyuTXQLCki9jq-HKL2-Ayo6G)]: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 27
at org.infinispan.statetransfer.StateTransferLockImpl.reportErrorAfterWait(StateTransferLockImpl.java:159) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:98) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:97) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:366) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:281) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:107) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1672) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.cache.impl.CacheImpl.putIfAbsentInternal(CacheImpl.java:1163) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.cache.impl.CacheImpl.putIfAbsent(CacheImpl.java:1151) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.cache.impl.DecoratedCache.putIfAbsent(DecoratedCache.java:508) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at org.infinispan.cache.impl.AbstractDelegatingCache.putIfAbsent(AbstractDelegatingCache.java:246) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:325) [rt.jar:1.8.0_72]
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.createValue(InfinispanSessionMetaDataFactory.java:53)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.createValue(InfinispanSessionMetaDataFactory.java:36)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:52)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:38)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.createSession(InfinispanSessionManager.java:257)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.createSession(DistributableSessionManager.java:110)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:787) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:802) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:131) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:88) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:80) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.FormAuthenticationMechanism.runFormAuth(FormAuthenticationMechanism.java:126) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.FormAuthenticationMechanism.authenticate(FormAuthenticationMechanism.java:96) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-13:
----------------------------------------
ProxyControllerRegistration.java: ProxyStepHandler needs to be HIDDEN for domain mode to work.
InstallationReportHandler.java needs to be HIDDEN for the product-info op to work properly in a domain.
ValidateOperationHandler.java: DEFINITION_PRIVATE needs to be HIDDEN for the validate-operation op to work properly in a domain.
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: EAP
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1541:
----------------------------------
Component/s: core engine
kie server
> newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1541
> URL: https://issues.jboss.org/browse/DROOLS-1541
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.3.0.Final, 6.5.0.Final
> Reporter: Daniel B.
> Assignee: Mario Fusco
>
> The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
> The documentation says:
> {quote}
> 11.2.2. InsertObjectCommand
> ...
> outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
> {quote}
> Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
> This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
> That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
> (It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1541:
-------------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1541
> URL: https://issues.jboss.org/browse/DROOLS-1541
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.5.0.Final
> Reporter: Daniel B.
> Assignee: Mario Fusco
>
> The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
> The documentation says:
> {quote}
> 11.2.2. InsertObjectCommand
> ...
> outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
> {quote}
> Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
> This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
> That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
> (It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years