[JBoss JIRA] (WFLY-6294) mod_cluster session drain wait does not end
by Aaron Ogburn (JIRA)
Aaron Ogburn created WFLY-6294:
----------------------------------
Summary: mod_cluster session drain wait does not end
Key: WFLY-6294
URL: https://issues.jboss.org/browse/WFLY-6294
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Aaron Ogburn
Assignee: Paul Ferraro
The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session:
{code}
while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) {
ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context);
listener.wait(noTimeout ? 0 : timeout);
current = System.currentTimeMillis();
timeout = end - current;
remainingSessions = context.getActiveSessionCount();
}
{code}
Can the listeners be invoked when the session is fully removed and no longer considered active?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Harold Campbell (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Harold Campbell commented on WFLY-6283:
---------------------------------------
Your laptop is probably too fast, if anything. I'm doing docker->KVM->host with spinning disks in RAID 1 configuration.
KVM:
$ grep -E '^model name|^cpu MHz' /proc/cpuinfo
model name : Intel Core Processor (Haswell, no TSX)
cpu MHz : 3398.030
model name : Intel Core Processor (Haswell, no TSX)
cpu MHz : 3398.030
model name : Intel Core Processor (Haswell, no TSX)
cpu MHz : 3398.030
model name : Intel Core Processor (Haswell, no TSX)
cpu MHz : 3398.030
KVM host:
$ grep -E '^model name|^cpu MHz' /proc/cpuinfo
model name : Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
cpu MHz : 3408.234
model name : Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
cpu MHz : 3400.132
model name : Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
cpu MHz : 3403.984
model name : Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
cpu MHz : 3400.132
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6283:
------------------------------------
Awesome to hear that Harold!
I'm trying to understand if my laptop is too slow or fast. Could you share the output of "grep -E '^model name|^cpu MHz' /proc/cpuinfo" in your test environment.
One the machine that I recreated:
{quote}
grep -E '^model name|^cpu MHz' /proc/cpuinfo
model name : QEMU Virtual CPU version (cpu64-rhel6)
cpu MHz : 2693.508
model name : QEMU Virtual CPU version (cpu64-rhel6)
cpu MHz : 2693.508
{quote}
On my T540 laptop which doesn't recreate:
{quote}
grep -E '^model name|^cpu MHz' /proc/cpuinfo
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3356.542
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3505.359
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3503.250
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3514.640
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3507.574
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3499.980
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3382.910
model name : Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
cpu MHz : 3524.027
{quote}
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (LOGMGR-124) Add marker support
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-124:
--------------------------------------
Ah okay it looks like there is some confusion. JBoss Logging (https://issues.jboss.org/projects/JBLOGGING) and JBoss Log Manager are two separate projects. JBoss Logging is a logging facade like slf4j. JBoss Log Manager is a log manager that extends JUL so more like logback.
There is also an [slf4j binding|https://github.com/jboss-logging/slf4j-jboss-logmanager] which uses JBoss Log Manager for the log manager. This allows users to use slf4j with JBoss Log Manager as their log manager which is what is done in WildFly and JBoss EAP.
JBoss Log Manager has no knowledge of slf4j or any other logging facade. We can't use slf4j's marker support so a new API would need to be added to JBoss Log Manager for the support.
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5990) jboss-web replication-granularity ATTRIBUTE causes IllegalStateException when getting attribute on the session
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5990?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5990:
--------------------------------------
Yes, UNDERTOW-622 was fixed in 1.3.16.Final Undertow release which was upgraded in WildFly for a while now.
> jboss-web replication-granularity ATTRIBUTE causes IllegalStateException when getting attribute on the session
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5990
> URL: https://issues.jboss.org/browse/WFLY-5990
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Environment: JDK 8u60
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> when using the replication granularity ATTRIBUTE as followed:
> {code}
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd"
> version="8.0">
> <replication-config>
> <replication-granularity>ATTRIBUTE</replication-granularity>
> </replication-config>
> </jboss-web>
> {code}
> using the following web cache container configuration (standalone-ha.xml of Wildfly 10.0.0.CR5):
> {code}
> <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
> <transport lock-timeout="60000"/>
> <distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
> <locking isolation="REPEATABLE_READ"/>
> <transaction mode="BATCH"/>
> </distributed-cache>
> </cache-container>
> {code}
> when getting an attribute over the session (i.e. httpServletRequest.getSession().getAttribute(...)) this will eventually result in:
> {code}
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-22) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=38}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:405)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:390)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionAttributes.getAttribute(FineSessionAttributes.java:71)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttribute(DistributableSession.java:133)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123)
> at XXX.XXX.core.filter.DevelopmentFilter.testSerialization(DevelopmentFilter.java:155)
> at XXX.XXX.core.filter.DevelopmentFilter.doDevelopmentFilter(DevelopmentFilter.java:133)
> at XXX.XXX.core.filter.DevelopmentFilter.doFilter(DevelopmentFilter.java:112)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.IERenderingFilter.doFilter(IERenderingFilter.java:80)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.KeepAliveFilter.doFilter(KeepAliveFilter.java:45)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.controller.HttpContextFilter.doFilter(HttpContextFilter.java:39)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.common.workers.HalogenHttpCachingFilter.doFilter(HalogenHttpCachingFilter.java:94)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.StaticContentVersionFilter.doFilter(StaticContentVersionFilter.java:73)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.LogFilter.doFilterInternal(LogFilter.java:182)
> at XXX.XXX.core.filter.LogFilter.doSuppressExceptionsFilterInternal(LogFilter.java:201)
> at XXX.XXX.core.filter.LogFilter.doFilter(LogFilter.java:160)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.common.language.LanguageFilter.invokeFilterChain(LanguageFilter.java:105)
> at XXX.XXX.common.language.LanguageFilter.doFilter(LanguageFilter.java:100)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.datasource.legacy.BindThreadLocalConnectionFilter$1.call(BindThreadLocalConnectionFilter.java:44)
> at XXX.XXX.datasource.legacy.BindThreadLocalConnectionFilter$1.call(BindThreadLocalConnectionFilter.java:41)
> at XXX.XXX.datasource.legacy.ThreadLocalConnectionAwareCallable.call(ThreadLocalConnectionAwareCallable.java:86)
> at XXX.XXX.datasource.legacy.ThreadLocalConnectionAwareCallable.withConnection(ThreadLocalConnectionAwareCallable.java:59)
> at XXX.XXX.datasource.legacy.BindThreadLocalConnectionFilter.doFilter(BindThreadLocalConnectionFilter.java:41)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.exception.ExceptionFilter.doSuppressExceptionsFilterInternal(ExceptionFilter.java:153)
> at XXX.XXX.core.exception.ExceptionFilter.doFilter(ExceptionFilter.java:134)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.web.request.RequestIdentifierFilter.doFilter(RequestIdentifierFilter.java:44)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
> at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
> at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
> at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:394)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {code}
> Does this mean that the replication granularity 'ATTRIBUTE' is no longer supported in Wildfly 10?
> if swapping the cache from "distributed" to "replicated" mode, we're getting instead an earlier NullPointerException:
> {code}
> ERROR [io.undertow.servlet.request] (default task-2) UT015012: Failed to generate error page /XXXX/error.jsp for original exception: null. Generating error page resulted in a 500.: java.lang.RuntimeException: org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.NullPointerException
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:156)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.NullPointerException
> at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:581)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:456)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:265)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:200)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:453)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:378)
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:154)
> ... 9 more
> Caused by: javax.servlet.ServletException: java.lang.NullPointerException
> at org.apache.jsp.error_jsp._jspService(error_jsp.java:102)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 25 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.interceptors.base.BaseStateTransferInterceptor.visitGetKeysInGroupCommand(BaseStateTransferInterceptor.java:50)
> at org.infinispan.commands.remote.GetKeysInGroupCommand.acceptVisitor(GetKeysInGroupCommand.java:95)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeysInGroupCommand(AbstractVisitor.java:178)
> at org.infinispan.commands.remote.GetKeysInGroupCommand.acceptVisitor(GetKeysInGroupCommand.java:95)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.internalGetGroup(CacheImpl.java:490)
> at org.infinispan.cache.impl.CacheImpl.getGroup(CacheImpl.java:483)
> at org.infinispan.cache.impl.CacheImpl.getGroup(CacheImpl.java:478)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.getGroup(AbstractDelegatingAdvancedCache.java:227)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionAttributesFactory.createValue(FineSessionAttributesFactory.java:73)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionAttributesFactory.createValue(FineSessionAttributesFactory.java:45)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.createSession(InfinispanSessionManager.java:255)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.createSession(DistributableSessionManager.java:107)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:741)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:137)
> at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:109)
> at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:60)
> at org.apache.jsp.error_jsp._jspService(error_jsp.java:80)
> ... 28 more
> {code}
> It the later, it looks like, in the command interceptor, the cache distribution manager is null, which kind of 'make sense' since we are no longer a distributed cache, but a replicated cache. Does it means that session replication is no longer supported and instead only session distribution is? In my case either way is fine, I'll just crank up the number of owner if only distribution is supported.
> Though, in my company usecase, session replication granularity 'attribute' is definitly required to migrate our application to Wildfly 10.
> I know there's still some open jira ticket to complement the Wildfly 10 documentation, but could you provide any additional insight if I've miss anything.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-923:
-----------------------------------------
Just an FYI: there is a blocking-timeout header that can be applied to all management operations. It's really not the same thing as an execution timeout though. Value is in seconds.
1) It's a server side timeout, not client side, so if for some reason execution doesn't complete due to some issue between the client and server, it has no impact.
2) It's not an overall limit on execution time. Rather, it controls how long blocking is allowed to continue in various points in the operation execution where the execution thread blocks waiting for some condition to be met (e.g. MSC service container stability, or responses from other processes in a managed domain.) The overall execution time can be longer than the blocking timeout though. For example with a domain-wide operation that is configured to roll out to each server in series, the blocking time per server could be fairly small, but with a lot of servers the overall time would be large.
The default value is 300s. It's basically meant to act as a failsafe to prevent blocking forever, with the header allowing users to set a lower or higher limit for unusual cases where they either know things will take a long time, or they know 300s is way too much and they want more rapid failure.
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1068) java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1068?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1068:
---------------------------------------
All of the tests for all of the projects execute using a Maven run configuration with a goal of 'test'.
I tried using a goal of 'test -Dtest=org.drools.compiler.integrationtests.AccumulateTest", I get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project kie-test-util: No tests were executed! (Set -DfailIfNoTests=false to ignore this error.) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project kie-test-util: No tests were executed! (Set -DfailIfNoTests=false to ignore this error.)
When I try to right click and 'Run as-> Junit', I get:
Class not found org.drools.compiler.integrationtests.AccumulateTest
java.lang.ClassNotFoundException: org.drools.compiler.integrationtests.AccumulateTest
at java.net.URLClassLoader.findClass(URLClassLoader.java:434)
at java.lang.ClassLoader.loadClass(ClassLoader.java:677)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:643)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClass(RemoteTestRunner.java:693)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClasses(RemoteTestRunner.java:429)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1068
> URL: https://issues.jboss.org/browse/DROOLS-1068
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: droolsReproducer.jar
>
>
> We have encountered this issue when we insert a fact matching a certain rule, delete the fact then call fire all rules.
> A reproducer is attached.
> -BillT
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months