[JBoss JIRA] (WFLY-5458) jgroups-stack & jgroups-channel attributes should not allow expressions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5458?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-5458 at 2/10/16 10:41 AM:
--------------------------------------------------------------
[~jmesnil] Why was jgroups-channel changed to not allow expressions? It is not a model reference - only jgroups-stack is a model reference.
was (Author: pferraro):
Why was jgroups-channel changed to not allow expressions? It is not a model reference - only jgroups-stack is a model reference.
> jgroups-stack & jgroups-channel attributes should not allow expressions
> -----------------------------------------------------------------------
>
> Key: WFLY-5458
> URL: https://issues.jboss.org/browse/WFLY-5458
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Paul Ferraro
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR4
>
>
> This attribute is a model reference, and therefore should not allow expressions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5437) Occassional stale data with remote EJB invocations and sync cache
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5437?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-5437:
--------------------------------------
[~rhusar] should not this issue be assign to [~mvinkler] ? (a least for clarity purpose)
> Occassional stale data with remote EJB invocations and sync cache
> -----------------------------------------------------------------
>
> Key: WFLY-5437
> URL: https://issues.jboss.org/browse/WFLY-5437
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR1
> Reporter: Richard Janík
> Assignee: Paul Ferraro
>
> Hi,
> we're occasionally getting stale data on remote EJB invocations (number counter returns number 1 lower than expected, see example). -This is usually preceded (~6 seconds before that) by cluster wide rebalance after a node is brought back from dead.-
> - 2000 clients, stale data is uncommon
> - requests from a single client are separated by a 4 second window.
> An example of stale data:
> {code}
> 2015/08/28 13:01:35:442 EDT [WARN ][Runner - 640] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Response serial does not match. Expected: 86, received: 85, runner: 640.>
> {code}
> And a link to our jobs if you're interested:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...
> This behavior has so far been observed with jvmkill and undeploy scenario, on REPL-SYNC and DIST-SYNC caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1367) Test framework for CLI-based tests can be very slow
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1367?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-902 to WFCORE-1367:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1367 (was: WFLY-902)
Component/s: CLI
Test Suite
(was: Test Suite)
> Test framework for CLI-based tests can be very slow
> ---------------------------------------------------
>
> Key: WFCORE-1367
> URL: https://issues.jboss.org/browse/WFCORE-1367
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Test Suite
> Reporter: David Bosschaert
> Priority: Minor
>
> The org.jboss.as.test.integration.management.base.AbstractCliTestBase provides a suitable API for testing CLI-based operations. However, running tests with a relatively large number of CLI operations can take a *long* time, seemingly much longer than necessary. This is probably related to the fact that CLIWrapper.readAllAsOpResult() method always seems to wait until the lineTimeout has expired.
> Typically the WAIT_LINETIMEOUT value is used for this argument. Shortening the timeout is not an option as I have seen cases where a test would fail when run on a slow machine, but this only happens occasionally.
> It would be *much* better if a timeout was not needed for this and the test would wait until a certain operation was finished.
> This can be observed in org.jboss.as.test.integration.management.cli.JmsTestCase and I also experienced it when writing the org.jboss.as.test.integration.osgi.management.OSGiManagementTestCase.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-2281) Exception from lifecycle callback interceptor method intercepting a session bean gets suppressed without log message
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2281?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2281:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1207240, https://bugzilla.redhat.com/show_bug.cgi?id=1253597, https://bugzilla.redhat.com/show_bug.cgi?id=1306329 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1253597, https://bugzilla.redhat.com/show_bug.cgi?id=1207240)
> Exception from lifecycle callback interceptor method intercepting a session bean gets suppressed without log message
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2281
> URL: https://issues.jboss.org/browse/WFLY-2281
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 8.0.0.Beta1
> Reporter: Matus Abaffy
> Assignee: Jozef Hartinger
> Fix For: 8.0.0.CR1
>
>
> From EJB spec., "9.3.3 Exceptions from AroundConstruct, PostConstruct and PreDestroy Lifecycle Callbacks", "Table 11" it follows that the container should log the exception or error thrown by a lifecycle callback interceptor method of a session bean or a message-driven bean.
> The thrown throwable gets suppressed. However, I cannot find any sign of it in the server log (using default settings - debug level).
> I'm not a spec. expert, but I think if the exception is not logged, it should at least not get suppressed. I made some tests that might be of help (available at https://github.com/bafco/wildfly/commits/WFLY-2281) - according to the spec., they probably don't have to pass.
--
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 Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-5990?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-5990:
----------------------------------------
Hi, I'd like to point out that I've tried Wildfly10.0.0.Final and replaced the embedded Infinispan 8.1.0.Final for Infinispan 8.1.1.Final that include https://github.com/infinispan/infinispan/pull/3993.
If I use ATTRIBUTE replication granularity I'm still getting the same exception as previously documented.
Though, if I'm using SESSION, it looks like I'm not seeing any issue within my application.
Is there anything I've missed?
> 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] (DROOLS-1058) Upgrade jaxb bundles from 2.2.10 to 2.2.11
by Petr Široký (JIRA)
Petr Široký created DROOLS-1058:
-----------------------------------
Summary: Upgrade jaxb bundles from 2.2.10 to 2.2.11
Key: DROOLS-1058
URL: https://issues.jboss.org/browse/DROOLS-1058
Project: Drools
Issue Type: Component Upgrade
Components: integration
Affects Versions: 6.4.0.Beta1
Reporter: Petr Široký
Assignee: Petr Široký
drools-karaf-features currently defines jaxb lib in version 2.2.10 which causes some issues on Fuse where the version is 2.2.11. We need to upgrade to that version, more so that this one is being used in KIE for a while now.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months