[JBoss JIRA] (WFLY-6082) NullPointerException on jar fetch from server by client
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-6082?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-6082:
-------------------------------------
Should? Please provide a JIRA? Will it be in 10 Final?
> NullPointerException on jar fetch from server by client
> -------------------------------------------------------
>
> Key: WFLY-6082
> URL: https://issues.jboss.org/browse/WFLY-6082
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Environment: RedHat 7 server
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> Reporter: George Turner
> Assignee: Stuart Douglas
>
> JNLP client requests is jars and this error is thrown for all requests, but the client successfully retrieves the jar(s)
> 2016-01-27 11:16:10,549 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /premiereclient/plugins/org.eclipse.swt.win32.win32.x86_64_3.103.2.v20150203-1351.jar: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.transferFrom(HttpResponseConduit.java:664)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.transferFrom(AbstractFixedLengthStreamSinkConduit.java:193)
> at org.xnio.conduits.ConduitStreamSinkChannel.transferFrom(ConduitStreamSinkChannel.java:142)
> at io.undertow.channels.DetachableStreamSinkChannel.transferFrom(DetachableStreamSinkChannel.java:127)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.transferFrom(HttpServerExchange.java:1951)
> at org.xnio.channels.Channels.transferBlocking(Channels.java:512)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.transferFrom(ServletOutputStreamImpl.java:528)
> at io.undertow.io.BlockingSenderImpl.performTransfer(BlockingSenderImpl.java:142)
> at io.undertow.io.BlockingSenderImpl.transferFrom(BlockingSenderImpl.java:135)
> at io.undertow.server.handlers.resource.PathResource$1TransferTask.run(PathResource.java:217)
> at io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:247)
> at io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:105)
> at org.wildfly.extension.undertow.deployment.ServletResource.serve(ServletResource.java:95)
> at io.undertow.server.handlers.resource.CachedResource.serve(CachedResource.java:168)
> at io.undertow.servlet.handlers.DefaultServlet.serveFileBlocking(DefaultServlet.java:358)
> at io.undertow.servlet.handlers.DefaultServlet.doGet(DefaultServlet.java:180)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 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)
> I can access the URL with a browser and see the list of the files using:
> http://localhost:8080/premiereclient/plugins/
> which is the same path shown in the error
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6056) Session.invalidate() exception with OPTIMISTIC cache configuration
by Juan AMAT (JIRA)
[ https://issues.jboss.org/browse/WFLY-6056?page=com.atlassian.jira.plugin.... ]
Juan AMAT commented on WFLY-6056:
---------------------------------
I guess that I must trust you on this one as I read the 'duplicate' ticket and I am not sure if I follow everything.
> Session.invalidate() exception with OPTIMISTIC cache configuration
> ------------------------------------------------------------------
>
> Key: WFLY-6056
> URL: https://issues.jboss.org/browse/WFLY-6056
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Juan AMAT
> Assignee: Paul Ferraro
>
> We have an application that must handle 'long' async requests and regular requests at the same time.
> We have the same problem as described here: https://developer.jboss.org/thread/254200
> If I use the configuration that is described in this discussion:
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <transaction locking="OPTIMISTIC"/>
> <locking isolation="READ_COMMITTED"/>
> <file-store/>
> </replicated-cache>
> then everything is fine until I call session.invalidate(). In this case I get an exception:
> Caused by: java.lang.UnsupportedOperationException: Calling lock() on non-transactional caches is not allowed
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:820)
> at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:136)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:124)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:89)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:67)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:439)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:181)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> Now I modify the configuration and specify <transaction mode="BATCH" locking="OPTIMISTIC"/>, I do get another exception:
> Caused by: org.infinispan.InvalidCacheUsageException: Explicit locking is not allowed with optimistic caches!
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitLockControlCommand(OptimisticLockingInterceptor.java:142)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 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.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 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.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:136)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:124)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:89)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:67)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:439)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:181)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> Is there some other configuration that I should use?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6071) Mixed domain test suite should test using the legacy domain.xml files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6071?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6071:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8618
> Mixed domain test suite should test using the legacy domain.xml files
> ---------------------------------------------------------------------
>
> Key: WFLY-6071
> URL: https://issues.jboss.org/browse/WFLY-6071
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave.
> This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join.
> This is basically what users will do -- take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311.
> So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release.
> We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found.
> That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6082) NullPointerException on jar fetch from server by client
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6082?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6082.
----------------------------------
Resolution: Duplicate Issue
This should already be fixed
> NullPointerException on jar fetch from server by client
> -------------------------------------------------------
>
> Key: WFLY-6082
> URL: https://issues.jboss.org/browse/WFLY-6082
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Environment: RedHat 7 server
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> Reporter: George Turner
> Assignee: Stuart Douglas
>
> JNLP client requests is jars and this error is thrown for all requests, but the client successfully retrieves the jar(s)
> 2016-01-27 11:16:10,549 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /premiereclient/plugins/org.eclipse.swt.win32.win32.x86_64_3.103.2.v20150203-1351.jar: java.lang.NullPointerException
> at io.undertow.server.protocol.http.HttpResponseConduit.transferFrom(HttpResponseConduit.java:664)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.transferFrom(AbstractFixedLengthStreamSinkConduit.java:193)
> at org.xnio.conduits.ConduitStreamSinkChannel.transferFrom(ConduitStreamSinkChannel.java:142)
> at io.undertow.channels.DetachableStreamSinkChannel.transferFrom(DetachableStreamSinkChannel.java:127)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.transferFrom(HttpServerExchange.java:1951)
> at org.xnio.channels.Channels.transferBlocking(Channels.java:512)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.transferFrom(ServletOutputStreamImpl.java:528)
> at io.undertow.io.BlockingSenderImpl.performTransfer(BlockingSenderImpl.java:142)
> at io.undertow.io.BlockingSenderImpl.transferFrom(BlockingSenderImpl.java:135)
> at io.undertow.server.handlers.resource.PathResource$1TransferTask.run(PathResource.java:217)
> at io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:247)
> at io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:105)
> at org.wildfly.extension.undertow.deployment.ServletResource.serve(ServletResource.java:95)
> at io.undertow.server.handlers.resource.CachedResource.serve(CachedResource.java:168)
> at io.undertow.servlet.handlers.DefaultServlet.serveFileBlocking(DefaultServlet.java:358)
> at io.undertow.servlet.handlers.DefaultServlet.doGet(DefaultServlet.java:180)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> 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)
> I can access the URL with a browser and see the list of the files using:
> http://localhost:8080/premiereclient/plugins/
> which is the same path shown in the error
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6056) Session.invalidate() exception with OPTIMISTIC cache configuration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6056?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6056.
------------------------------
Resolution: Duplicate Issue
Duplicate of WFLY-5998.
> Session.invalidate() exception with OPTIMISTIC cache configuration
> ------------------------------------------------------------------
>
> Key: WFLY-6056
> URL: https://issues.jboss.org/browse/WFLY-6056
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Juan AMAT
> Assignee: Paul Ferraro
>
> We have an application that must handle 'long' async requests and regular requests at the same time.
> We have the same problem as described here: https://developer.jboss.org/thread/254200
> If I use the configuration that is described in this discussion:
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <transaction locking="OPTIMISTIC"/>
> <locking isolation="READ_COMMITTED"/>
> <file-store/>
> </replicated-cache>
> then everything is fine until I call session.invalidate(). In this case I get an exception:
> Caused by: java.lang.UnsupportedOperationException: Calling lock() on non-transactional caches is not allowed
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:820)
> at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:136)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:124)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:89)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:67)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:439)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:181)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> Now I modify the configuration and specify <transaction mode="BATCH" locking="OPTIMISTIC"/>, I do get another exception:
> Caused by: org.infinispan.InvalidCacheUsageException: Explicit locking is not allowed with optimistic caches!
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitLockControlCommand(OptimisticLockingInterceptor.java:142)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 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.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> 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.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> at org.infinispan.cache.impl.DecoratedCache.lock(DecoratedCache.java:136)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:124)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:89)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:67)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:439)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:181)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199)
> Is there some other configuration that I should use?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6063) Testsuite: with introduction of "private" default interface revise need for added "multicast" interface
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6063?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6063:
---------------------------------
Summary: Testsuite: with introduction of "private" default interface revise need for added "multicast" interface (was: Testsuite: with introduction of "private" default interface there is no need for "multicast" interface in the testsuite)
> Testsuite: with introduction of "private" default interface revise need for added "multicast" interface
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6063
> URL: https://issues.jboss.org/browse/WFLY-6063
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR5
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> Which means we can get rid of testsuite/integration/src/test/xslt/changeJGroupsMulticastInterface.xsl and the uses of it.
> As part of this, we can make this configurable from the testsuite parameters (would that be useful?).
> Logic was introduced for WFLY-3984.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months