[JBoss JIRA] (ELY-300) Absence of key-store-credential NPEs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-300?page=com.atlassian.jira.plugin.sy... ]
David Lloyd updated ELY-300:
----------------------------
Component/s: Authentication Client
> Absence of key-store-credential NPEs
> ------------------------------------
>
> Key: ELY-300
> URL: https://issues.jboss.org/browse/ELY-300
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Kabir Khan
> Assignee: David Lloyd
> Fix For: 1.1.0.Alpha1
>
>
> Trying to parse
> {code}
> <authentication-client xmlns="urn:elytron:1.0">
> <key-stores>
> <key-store name="test" type="PasswordFile">
> <file name="keystore/xml-client-keystore-credential-test.keystore"/>
> <!--<key-store-credential key-store-name="test" alias="test-alias"/>-->
> </key-store>
> </key-stores>
> </authentication-client>
> {code}
> I end up with
> {code}
> java.lang.NullPointerException
> at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1082)
> at org.wildfly.security.auth.client.ElytronXmlParser$AbstractKeyStoreFactory.create(ElytronXmlParser.java:1067)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$115(ElytronXmlParser.java:709)
> at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$4/1929600551.create(Unknown Source)
> at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:47)
> at org.wildfly.security.auth.client.KeyStoreEntrySecurityFactory.create(KeyStoreEntrySecurityFactory.java:30)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$106(ElytronXmlParser.java:425)
> at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$5/1053782781.create(Unknown Source)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRuleType$113(ElytronXmlParser.java:474)
> at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$6/2012232625.create(Unknown Source)
> at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationClientRulesType$88(ElytronXmlParser.java:242)
> at org.wildfly.security.auth.client.ElytronXmlParser$$Lambda$7/627150481.create(Unknown Source)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45)
> at org.wildfly.security.auth.client.XmlClientKeyStoreCredentialTest.testKeystoreCredential(XmlClientKeyStoreCredentialTest.java:110)
> {code}
> This appears to be because the passwordFactory is only instantiated when parsing the key-store-credential element
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Darran Lofthouse commented on WFCORE-306:
-----------------------------------------
Just scheduling so it is considered, not committing to the exact release as this is still lower priority than some other tasks.
We are in the process of exposing the management of users as management operations so the CLI is looking more appropriate for this to be wrapped in a CLI command - in addition to this the CLI also has the support for embedded mode so management of users can happen whether the server is up or not.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-306:
---------------------------------------
Assignee: Darran Lofthouse
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-306) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-306?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-306:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFCORE-306
> URL: https://issues.jboss.org/browse/WFCORE-306
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha1
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5558) Redundant security-related XML schema files
by Martin Švehla (JIRA)
[ https://issues.jboss.org/browse/WFLY-5558?page=com.atlassian.jira.plugin.... ]
Martin Švehla moved JBEAP-1586 to WFLY-5558:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5558 (was: JBEAP-1586)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Security
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR3
(was: 7.0.0.DR12 (Alpha))
> Redundant security-related XML schema files
> -------------------------------------------
>
> Key: WFLY-5558
> URL: https://issues.jboss.org/browse/WFLY-5558
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR3
> Reporter: Martin Švehla
>
> There are several XML schemas in server's docs/schemas that are in my opinion redundant and should be removed:
> * picketbox-security-domain-configuration_4_0.xsd - duplicates subsystem configuration in jboss-as-security_1_2.xsd
> * security-config_*.xsd - 3 schemas for old deployable security configuration descriptor. These kinds of deployments are afaik not supported in EAP 7.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5501) JDBC Object Store problem with Mariadb55
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5501?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5501:
--------------------------------
Priority: Critical (was: Major)
> JDBC Object Store problem with Mariadb55
> ----------------------------------------
>
> Key: WFLY-5501
> URL: https://issues.jboss.org/browse/WFLY-5501
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Hayk Hovsepyan
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 10.0.0.CR4
>
> Attachments: mariadb_jar.zip, server.log, standalone.xml
>
>
> When configuring transactions to use Mariadb55 Datasource as a JDBC Object store, server fails to start with error:
> {code}
> 13:56:51,485 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaRecoveryManager" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: WFLYTX0005: Recovery manager create failed
> Caused by: java.lang.NullPointerException"}}
> {code}
> Steps to reproduce:
> 1. Create Mariadb55 JDBC driver module. Module archived directory is attached.
> 2. Add driver into configuration xml.
> 3. Create Datasource pointing to Mariadb55 database and using driver configured a a module.
> 4. Configure transactions to use jdbc-store the added Datasource. standalone.xml is attached.
> 5. Server fails to start. server.log is attached.
> config xml file part:
> {code}
> <subsystem xmlns="urn:jboss:domain:datasources:4.0">
> <datasources>
> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
> <driver>h2</driver>
> <security>
> <user-name>sa</user-name>
> <password>sa</password>
> </security>
> </datasource>
> <datasource jta="false" jndi-name="java:jboss/datasources/jdbc-store" pool-name="JDBCObjectStore" enabled="true" use-java-context="true">
> <connection-url>jdbc:mariadb://db22.mw.lab.eng.bos.redhat.com:3306/dballo17</connection-url>
> <driver>module_mariadb.jar</driver>
> <security>
> <user-name>dballo17</user-name>
> <password>dballo17</password>
> </security>
> </datasource>
> <drivers>
> <driver name="h2" module="com.h2database.h2">
> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
> </driver>
> <driver name="module_mariadb.jar" module="mariadb_jar"/>
> </drivers>
> </datasources>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:transactions:3.0">
> <core-environment>
> <process-id>
> <uuid/>
> </process-id>
> </core-environment>
> <recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
> <coordinator-environment enable-tsm-status="true"/>
> <jdbc-store datasource-jndi-name="java:jboss/datasources/jdbc-store"/>
> </subsystem>
> {code}
> Attached necessary info:
> 1. server.log
> 2. Module zip to extract in $JBOSS_HOME/modules/system/layers/base
> 3. standalone.xml
> Notes:
> The same steps works for other databases.
> When step 4. is not executed server starts successfully, so module is recognized.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5539) Infinispan subsystem attributes are not persisted
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5539?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek closed WFLY-5539.
-------------------------------------
Resolution: Rejected
[~pferraro] Thanks for the hint, Paul. I'll try to programatically tinker with Infinispan subsystem caches defined in {{standalone-ha.xml}} from within the runtime of my deployment.
I'm closing this Issue and I'll move to the user forum with any further inquires.
> Infinispan subsystem attributes are not persisted
> -------------------------------------------------
>
> Key: WFLY-5539
> URL: https://issues.jboss.org/browse/WFLY-5539
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR2
> Reporter: Michal Karm Babacek
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 10.0.0.CR4
>
>
> Certain cache configuration attributes are not persisted after reload. I find this issue being a critical one because if effectively prevents me from enabling indexing on my custom caches.
> For instance, there are no attributes *indexing* nor *batching* in the [jboss-as-infinispan_4_0.xsd|https://github.com/wildfly/wildfly/blob/maste...], whereas CLI allows one to set these; nonetheless in vain, because the values are not persisted.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=batching)
> {
> "outcome" => "success",
> "result" => false
> }
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=indexing)
> {
> "outcome" => "success",
> "result" => "NONE"
> }
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:write-attribute(name=indexing,value=ALL)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:write-attribute(name=batching,value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] reload
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=indexing)
> {
> "outcome" => "success",
> "result" => "NONE"
> }
> [standalone@localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=batching)
> {
> "outcome" => "success",
> "result" => false
> }
> {noformat}
> Is there any other way how one could enable indexing on one's cache? E.g. my cache:
> {code}
> <replicated-cache name="BLACKLIST_CACHE" mode="ASYNC">
> <locking acquire-timeout="60000" concurrency-level="3000" isolation="REPEATABLE_READ"/>
> <transaction mode="NONE"/>
> <eviction max-entries="10000000" strategy="NONE"/>
> <expiration interval="-1" lifespan="-1" max-idle="-1"/>
> <file-store/>
> <state-transfer timeout="300000"/>
> </replicated-cache>
> {code} Obviously, adding aforementioned attributes to the cache element results in an XML parsing error...
> Last but not least, is there any way how to circumvent the bug and force indexing so as to avoid deadly exceptions such as: {noformat}java.lang.IllegalArgumentException: Indexing was not enabled on this cache. interface org.hibernate.search.spi.SearchIntegrator not found in registry{noformat}? I'm very well aware of the possibility to configure the whole cache programatically in runtime using CacheManager -- but that is the very situation I was trying to migrate away from.
> Thx for comments.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5011) OutdatedTopologyException: Cache not running on node <node_name>
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5011?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek commented on WFLY-5011:
-------------------------------------------
[~pferraro], [~mvinkler] Apart from {{OutdatedTopologyException}}, I experience also the infamous {{ISPN000329: Unable to read rebalancing status from coordinator}}. I have a hunch these are closely related; hence this comment and not a new JIRA.
The test is dead simple, with no load whatsoever -- merely several requests to establish sessions.
* balancer: Apache HTTP Server with mod_cluster
* worker: {{jboss-eap-7.0}} [jboss-eap-7.0.log|https://gist.github.com/Karm/7fe27a2c9aaac40e1b0d#file-...]
* worker: {{jboss-eap-7.0-2}} [jboss-eap-7.0-2.log|https://gist.github.com/Karm/7fe27a2c9aaac40e1b0d#fil...]
* worker: {{jboss-eap-7.0-3}} [jboss-eap-7.0-3.log|https://gist.github.com/Karm/7fe27a2c9aaac40e1b0d#fil...]
All workers run; {{jboss-eap-7.0}} worker is killed, i.e. its JVM is killed; then {{jboss-eap-7.0-2}} worker, to which the failover occurred, stars returning HTTP 500 Errors due to:
{noformat}2015-10-20 14:03:47,293 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /clusterbench/requestinfo/: org.infinispan.statetransfer.OutdatedTopologyException: Cache not running on node jboss-eap-7.0, or the node is missing{noformat} Simultaneously, {{jboss-eap-7.0-3}} worker starts complaining about the dead coordinator:{noformat}2015-10-20 14:03:47,306 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (ServerService Thread Pool -- 64) ISPN000329: Unable to read rebalancing status from coordinator jboss-eap-7.0: org.infinispan.remoting.transport.jgroups.SuspectException: Cache not running on node jboss-eap-7.0
at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:46)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:753)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$80(JGroupsTransport.java:589)
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30)
at org.jgroups.blocks.Request.checkCompletion(Request.java:169)
at org.jgroups.blocks.UnicastRequest.viewChange(UnicastRequest.java:164)
at org.jgroups.blocks.RequestCorrelator.receiveView(RequestCorrelator.java:331)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:242)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:684)
at org.jgroups.JChannel.up(JChannel.java:738)
at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:123)
at org.jgroups.stack.Protocol.up(Protocol.java:374)
at org.jgroups.protocols.FORK.up(FORK.java:118)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:735)
at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:140)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:925)
at org.jgroups.stack.Protocol.up(Protocol.java:412)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982)
at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
at org.jgroups.protocols.Discovery.up(Discovery.java:295)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1796)
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)
{noformat}
h3. Question
Could I white-list the *ISPN000329* exception in my tests or is it actually related to the grave problem of {{OutdatedTopologyExceptions}} on the other node? Last but not least, lemme stress one more time that there is virtually no load whatsoever; this is a functional test with a handful of requests running on a one physical Solaris machine.
> OutdatedTopologyException: Cache not running on node <node_name>
> ----------------------------------------------------------------
>
> Key: WFLY-5011
> URL: https://issues.jboss.org/browse/WFLY-5011
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
>
> Seen in our HTTP-based failover tests (no matter what failover type: jvmkill/shutdown/undeploy), with *distributed* cache used.
> Doe not occur when replicated cache is used.
> Setup: 4 node cluster, one node at time is shutdown, while standalone clients keep calling the application.
> After failing one node(failover type: jvmkill/shutdown/undeploy) - perf18 for example, perf19,20,21 log the following error message many times (seems like one error per each session)
> {code}
> [JBossINF] [0m[31m05:48:40,646 ERROR [io.undertow.request] (default task-110) UT005023: Exception handling request to /clusterbench/session: org.infinispan.statetransfer.OutdatedTopologyException: Cache not running on node perf18
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.checkTxCommandResponses(TxDistributionInterceptor.java:274)
> [JBossINF] at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitLockControlCommand(TxDistributionInterceptor.java:186)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:174)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.acquireRemoteIfNeeded(PessimisticLockingInterceptor.java:238)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:66)
> [JBossINF] at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:70)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:346)
> [JBossINF] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:318)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:364)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:349)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103)
> [JBossINF] at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:91)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> [JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> [JBossINF] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:86)
> [JBossINF] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> [JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:430)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:427)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:287)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:120)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:56)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:232)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:116)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:725)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:367)
> [JBossINF] at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:231)
> [JBossINF] at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:281)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months