[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:
------------------------------------
[~mvinkler] Can you validate whether or not this is still and issue now that https://issues.jboss.org/browse/WFLY-9890 is fixed?
> 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
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> 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.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2366) AsyncDispatcher configuration in ErraiService.properties throws ClassNotFoundException
by Dhamodharan Krishnan (JIRA)
Dhamodharan Krishnan created DROOLS-2366:
--------------------------------------------
Summary: AsyncDispatcher configuration in ErraiService.properties throws ClassNotFoundException
Key: DROOLS-2366
URL: https://issues.jboss.org/browse/DROOLS-2366
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.Final
Reporter: Dhamodharan Krishnan
Assignee: Mario Fusco
I have tried to configure the above mentioned step to recover the Workbench from slowness
/WEB-INF/classes/ErraiService.properties.
But it does not seem to have any effect on the performance. Workbench is continuing to be slow.
Everyone started complaining about the performance. Sometimes, it is not responsible at all.
I have seen more additional information and tried to configure AsyncDispatcher.
But it throws a ClassNotFoundException even though the corresponding jar is available.
( errai-bus-3.2.4.Final.jar ).
http://docs.jboss.org/errai/1.3.2.Final/errai/reference/html/sid-5931334....
tomcat-workbench/webapps/kie-wb/WEB-INF/classes/ErraiService.properties
--
##
## Request dispatcher implementation (default is SimpleDispatcher)
##
#errai.dispatcher_implementation=org.jboss.errai.bus.server.SimpleDispatcher
errai.dispatcher_implementation=org.jboss.errai.bus.server.AsyncDispatcher
#
## Worker pool size. This is the number of threads the asynchronous worker pool should provide for
processing
## incoming messages. This option is only valid when using the AsyncDispatcher implementation.
##
errai.async.thread_pool_size=10
##
## Worker timeout (in seconds). This defines the time that a single asychronous process may run,
before the worker pool
## terminates it and reclaims the thread. This option is only valid when using the AsyncDispatcher
implementation.
##
errai.async.worker.timeout=30
##
## Specify the Authentication/Authorization Adapter to use
##
#errai.authentication_adapter=org.jboss.errai.persistence.server.security.HibernateAuthenticationAdapter
#errai.authentication_adapter=org.jboss.errai.bus.server.security.auth.JAASAdapter
##
## This property indicates whether or not authentication is required for all communication with the
bus. Set this
## to 'true' if all access to your application should be secure.
##
#errai.require_authentication_for_all=false
#disable the Workbench's use of Server Sent Events
errai.bus.enable_sse_support=false
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9917) renewal of server certificate for Undertow without restarting server
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9917?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-9917 at 3/5/18 4:03 PM:
----------------------------------------------------------
As solution by keystore files content change is already implemented and working and solution based on model change is in conflict with decision to not implement more attribute-change-without-reload features (see WFCORE-1953), going to close this.
was (Author: honza889):
As solution by keystore files content change is already implemented and working and solution based on model change is in conflict with decision to not implement more attribute-change-without-reload features, going to close this.
> renewal of server certificate for Undertow without restarting server
> --------------------------------------------------------------------
>
> Key: WFLY-9917
> URL: https://issues.jboss.org/browse/WFLY-9917
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 11.0.0.Final
> Reporter: Hisanobu Okuda
> Assignee: Jan Kalina
>
> It is convenient that a server certificate for https interface can be renewed without restarting a server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (SWSQE-53) Service Graph does not dynamically update when scaling a Service pod to '0'
by Matt Mahoney (JIRA)
[ https://issues.jboss.org/browse/SWSQE-53?page=com.atlassian.jira.plugin.s... ]
Matt Mahoney deleted SWSQE-53:
------------------------------
> Service Graph does not dynamically update when scaling a Service pod to '0'
> ---------------------------------------------------------------------------
>
> Key: SWSQE-53
> URL: https://issues.jboss.org/browse/SWSQE-53
> Project: Swift Sunshine QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Michael Foley
>
> The Service Graph does not dynamically update to reflect that a Service pod was scaled to '0'. A browser refresh must be done to get updated Service data.
> Reproduction steps:
> - Deploy Istiio config + SWS
> - Deploy BookInfo
> - Generate traffic to the app
> - In browser, navigate to Service Graph -> Istio-System Namespace
> - Note that the service connections to Ratings V1 service should be GREEN
> - Scale the Ratings V1 service to '0'
> - Observe that the Service Graph does NOT update the Ratings V1 service connections to 'black' without a browser refresh.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1523) Update the JAPICMP settings so that we only detect changes that break API compatibility
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1523?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1523:
----------------------------
Description: Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API. (was: Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API.
As an example, try building the 1.2.1.Final tag (https://github.com/wildfly-security/wildfly-elytron/tree/1.2.1.Final). The build will fail due to new public API unless the -DskipCompatibility flag is passed in.)
> Update the JAPICMP settings so that we only detect changes that break API compatibility
> ---------------------------------------------------------------------------------------
>
> Key: ELY-1523
> URL: https://issues.jboss.org/browse/ELY-1523
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Farah Juma
> Assignee: Jan Kalina
>
> Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (SWSQE-53) Service Graph does not dynamically update when scaling a Service pod to '0'
by Matt Mahoney (JIRA)
Matt Mahoney created SWSQE-53:
---------------------------------
Summary: Service Graph does not dynamically update when scaling a Service pod to '0'
Key: SWSQE-53
URL: https://issues.jboss.org/browse/SWSQE-53
Project: Swift Sunshine QE
Issue Type: Task
Reporter: Matt Mahoney
Assignee: Michael Foley
The Service Graph does not dynamically update to reflect that a Service pod was scaled to '0'. A browser refresh must be done to get updated Service data.
Reproduction steps:
- Deploy Istiio config + SWS
- Deploy BookInfo
- Generate traffic to the app
- In browser, navigate to Service Graph -> Istio-System Namespace
- Note that the service connections to Ratings V1 service should be GREEN
- Scale the Ratings V1 service to '0'
- Observe that the Service Graph does NOT update the Ratings V1 service connections to 'black' without a browser refresh.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months