[JBoss JIRA] (WFLY-9952) TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-9952?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-9952:
------------------------------------
[~tommaso-borgato] OK - this is probably due to https://issues.jboss.org/browse/ISPN-9701
Additionally, we should be running any "async" jobs anymore. Only "sync".
> TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9952
> URL: https://issues.jboss.org/browse/WFLY-9952
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Beta1, 14.0.0.Beta2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
>
> The issue does not produce errors on the client side, only an ERROR entry in the server logs.
> Seen in: stress-session-repl-sync
> Other scenarios are likely affected as well.
> Besides servers logging WFLY-9890 constantly, thie issue has also been observed:
> {code}
> [JBossINF] [0m[31m13:15:02,901 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (default task-32) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey(Tp9qx2zySUrgdPpmDZV4HXbfUV_61KM5GZJR0fD4) and requestor GlobalTx:dev212:8863128. Lock is held by GlobalTx:dev212:8860838
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:253)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:269)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:161)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:83)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireLocalLock(PessimisticLockingInterceptor.java:93)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:110)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> [JBossINF] at org.infinispan.interceptors.impl.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:374)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:41)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:189)
> [JBossINF] at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.handleReadCommand(BaseStateTransferInterceptor.java:191)
> [JBossINF] at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.visitGetKeyValueCommand(BaseStateTransferInterceptor.java:174)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
> [JBossINF] at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:96)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:60)
> [JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> [JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> [JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> [JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:500)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:495)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> [JBossINF] at org.infinispan.cache.impl.EncoderCache.get(EncoderCache.java:637)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:74)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:64)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:36)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:60)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:38)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:191)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:176)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:858)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:414)
> [JBossINF] at org.jboss.weld.module.web.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:241)
> [JBossINF] at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {code}
> Clients get HTTP 500 response:
> {code}
> 2018/03/04 13:15:02:903 EST [WARN ][Runner - 227] HOST dev220.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:164)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10638) Eliminate "Transactional caches are not supported." log warning from ORM 5.3.* deployments
by Frank Langelage (Jira)
[ https://issues.jboss.org/browse/WFLY-10638?page=com.atlassian.jira.plugin... ]
Frank Langelage commented on WFLY-10638:
----------------------------------------
Using current master now (wildfly-15.0.0.CR1-SNAPSHOT as of today) the warnings are still present:
27.11. 22:33:41,144 WARN [org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions] HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset.
27.11. 22:33:41,153 WARN [org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions] HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset.
27.11. 22:33:41,159 WARN [org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions] HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset.
27.11. 22:33:41,162 WARN [org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions] HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset.
File wildfly/dist/target/wildfly-15.0.0.CR1-SNAPSHOT/standalone/configuration/standalone-full.xml still looks like this:
{code:xml}
<cache-container name="hibernate" module="org.infinispan.hibernate-cache">
<local-cache name="entity">
* <transaction mode="NON_XA"/>*
<object-memory size="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="local-query">
<object-memory size="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<local-cache name="timestamps"/>
</cache-container>
{code:xml}
> Eliminate "Transactional caches are not supported." log warning from ORM 5.3.* deployments
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-10638
> URL: https://issues.jboss.org/browse/WFLY-10638
> Project: WildFly
> Issue Type: Task
> Components: Clustering, JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 15.0.0.Beta1
>
>
> Currently, during deployment of ORM 5.3.* applications, the following warning is logged in the server console, four times per persistence unit. It should not appear at all.
> {quote}
> HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset.
> {quote}
> The warning comes from ORM 5.3 integration code org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (LOGMGR-86) Create an exception filter
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-86?page=com.atlassian.jira.plugin.... ]
James Perkins commented on LOGMGR-86:
-------------------------------------
Yeah. In WildFly we don't currently allow for custom filters. However I think we should and this could likely just go away.
> Create an exception filter
> --------------------------
>
> Key: LOGMGR-86
> URL: https://issues.jboss.org/browse/LOGMGR-86
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: James Perkins
> Priority: Major
>
> For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFCORE-4170) The vault resource needs to expose a capability that requires the picketbox package
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFCORE-4170?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-4170:
------------------------------------------
I wonder if at some point we should revisit not including PB in core. The PB jars themselves add about 1MB but at this point the core zip is 30MB so this isn't a big difference, and not shipping it results in ugly hacks. And the galleon layer stuff can help users reach the key objective of not including it in their dist regardless of what FP it is shipped in.
One caution though is the org.picketbox module comes with a ton of dependencies most of which should not be in core even if PB was. Mostly optional ones, and others perhaps could be.
{code}
<module name="org.picketbox" xmlns="urn:jboss:module:1.5">
<!-- This module is deprecated and subject to being removed in a subsequent release. -->
<properties>
<property name="jboss.api" value="deprecated"/>
</properties>
<resources>
<resource-root path="picketbox-5.0.3.Final.jar"/>
<resource-root path="picketbox-infinispan-5.0.3.Final.jar"/>
<resource-root path="picketbox-commons-1.0.0.final.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.persistence.api" optional="true"/>
<module name="javax.resource.api" optional="true"/>
<module name="javax.security.auth.message.api" optional="true"/>
<module name="javax.security.jacc.api"/>
<module name="javax.servlet.api"/>
<module name="javax.transaction.api" optional="true"/>
<module name="javax.xml.bind.api" optional="true"/>
<module name="javax.xml.stream.api" optional="true"/>
<module name="org.jboss.logging"/>
<module name="org.infinispan" optional="true"/>
<module name="org.jboss.security.xacml" optional="true"/>
<module name="org.jboss.modules" optional="true"/>
<module name="sun.jdk"/>
</dependencies>
</module>
{code}
I'm not advocating making this any kind of a priority, particularly if it wouldn't be simple.
> The vault resource needs to expose a capability that requires the picketbox package
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-4170
> URL: https://issues.jboss.org/browse/WFCORE-4170
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Major
>
> The picketbox module is optional in core, but there is no link from configuration to a hard requirement for PB. The result is Galleon could theoretically provision a server with a vault in the config but not PB module on the FS. The way to add such a link is via a capability for vault and the use of RuntimeCapability.Builder.addAdditionalRequiredPackages.
> Note that I think this means the vault feature can't be part of any layer in core, or at least not a layer that's depended upon by any 'default' core layer. This is because the PB module will not be part of the core feature pack.
> [~jfdenise] FYI; this is a follow up to our conversation earlier today.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3098) UX: Add support for data object List
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3098?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3098:
--------------------------------
Description:
As user I want to be able to use Data Objects that contain Lists and Maps.
Preconditions: New feature of current implementation.
was:As user I want to be able to use Data Objects that contain Lists and Maps
> UX: Add support for data object List
> ------------------------------------
>
> Key: DROOLS-3098
> URL: https://issues.jboss.org/browse/DROOLS-3098
> Project: Drools
> Issue Type: Story
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Liz Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
>
> As user I want to be able to use Data Objects that contain Lists and Maps.
> Preconditions: New feature of current implementation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months