[JBoss JIRA] (WFLY-4681) Reevaluation of java memory settings
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFLY-4681?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on WFLY-4681:
---------------------------------------
Hello all,
I've been checking the GC logs generated by starting WildFly 10.0.0.CR5 in standalone mode, and I can see the metaspace is being exausted several times, which triggers full GCs before the JVM decides to scale up the metaspace.
By setting {{-XX:MetaspaceSize=64m}} I do benefit from a ~15% faster boot time.
According to JConsole a just-started WildFly instance requires approximately 55MB of metaspace, while the default is around 20MB according to {{-XX:+PrintFlagsFinal}} on my machine (JDK8, 64bit linux). So I'd suggest setting this to 64mb as a starting point, it will of course scale up automatically depending of deployed application needs but this is the least it needs at boot to prevent it from chocking on those full GCs.
> Reevaluation of java memory settings
> ------------------------------------
>
> Key: WFLY-4681
> URL: https://issues.jboss.org/browse/WFLY-4681
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Andrig Miller
>
> Based on [~ctomc]'s comment in https://issues.jboss.org/browse/JBEAP-149,
> perf team should do some testing and suggest best values for java memory settings in WildFly (-Xms, -Xmx, ...). This settings need to be completely reevaluated as EAP7 moved to JDK8 as requirement.
> JDK8 doesn't have PermGen space anymore but metaspace, this completely changes how memory settings need to be tuned.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Ståle Pedersen commented on WFCORE-1277:
----------------------------------------
hm, atm i have a lot on my plate, so just to get this working. ill revert my changes for now, and use your pr [~soul2zimate]. ill let you know when i have that deployed on mvn for you to test.
- ill try to put off time later to fix this a better way.
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Ståle Pedersen
> Priority: Minor
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5991) org.eclipse.jdt.ecj module should be private
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5991?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved JBEAP-2775 to WFLY-5991:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5991 (was: JBEAP-2775)
Issue Type: Task (was: Bug)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR5
(was: 7.0.0.ER4)
> org.eclipse.jdt.ecj module should be private
> --------------------------------------------
>
> Key: WFLY-5991
> URL: https://issues.jboss.org/browse/WFLY-5991
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
>
> I believe we don't want to support this module. AFAIK it's used only internally by Undertow to compile JSPs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5785) EJB lookup fails with "No cluster context available" in failover tests
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5785?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5785:
------------------------------------
I'll take this over with a better fix.
> EJB lookup fails with "No cluster context available" in failover tests
> ----------------------------------------------------------------------
>
> Key: WFLY-5785
> URL: https://issues.jboss.org/browse/WFLY-5785
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Dominik Pospisil
>
> Seen in our failover tests for remote stateful EJBs - scenarios:
> ejb-ejbremote-shutdown-dist-async
> ejb-ejbremote-shutdown-dist-sync
> ejb-ejbremote-undeploy-dist-async
> After failing a node, occasionally EJB lookup starts failing - client starts logging these error messages:
> {code}
> 2015/12/03 04:46:47:078 EST [ERROR][Runner - 9] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb>
> java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:1063)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> 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:745)
> {code}
> It stops logging these messages only after the failed node is restarted and joins the cluster again.
> Link (this job was configured to use only 100 sessions in order to keep the log size small)
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5785) EJB lookup fails with "No cluster context available" in failover tests
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5785?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-5785:
----------------------------------
Assignee: Paul Ferraro (was: Dominik Pospisil)
> EJB lookup fails with "No cluster context available" in failover tests
> ----------------------------------------------------------------------
>
> Key: WFLY-5785
> URL: https://issues.jboss.org/browse/WFLY-5785
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Seen in our failover tests for remote stateful EJBs - scenarios:
> ejb-ejbremote-shutdown-dist-async
> ejb-ejbremote-shutdown-dist-sync
> ejb-ejbremote-undeploy-dist-async
> After failing a node, occasionally EJB lookup starts failing - client starts logging these error messages:
> {code}
> 2015/12/03 04:46:47:078 EST [ERROR][Runner - 9] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb>
> java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:1063)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> 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:745)
> {code}
> It stops logging these messages only after the failed node is restarted and joins the cluster again.
> Link (this job was configured to use only 100 sessions in order to keep the log size small)
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1025) NPE removing a rule that contains a subnetwork
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1025:
-----------------------------------
Summary: NPE removing a rule that contains a subnetwork
Key: DROOLS-1025
URL: https://issues.jboss.org/browse/DROOLS-1025
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Removing a rule containing a subnetwork causes the following NPE:
{code}
java.lang.NullPointerException
at org.drools.core.phreak.AddRemoveRule.deletePeerLeftTuple(AddRemoveRule.java:777)
at org.drools.core.phreak.AddRemoveRule.followPeer(AddRemoveRule.java:749)
at org.drools.core.phreak.AddRemoveRule.processLeftTuples(AddRemoveRule.java:713)
at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:281)
at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:153)
at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173)
at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163)
at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635)
at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626)
at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610)
at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5990) jboss-web replication-granularity ATTRIBUTE causes IllegalStateException when getting attribute on the session
by Mathieu Lachance (JIRA)
Mathieu Lachance created WFLY-5990:
--------------------------------------
Summary: 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, 3 months