[JBoss JIRA] (WFLY-6512) Missing explanation which services failed to start
by Fedor Gavrilov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6512?page=com.atlassian.jira.plugin.... ]
Fedor Gavrilov moved JBEAP-4181 to WFLY-6512:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6512 (was: JBEAP-4181)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Server)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER6)
> Missing explanation which services failed to start
> --------------------------------------------------
>
> Key: WFLY-6512
> URL: https://issues.jboss.org/browse/WFLY-6512
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Fedor Gavrilov
> Assignee: Fedor Gavrilov
>
> Missing info which services failed to start on server startup
> E.g. when I change in mod_cluster subsystem connector reference to invalid one (/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=connector, value=invalid), the server fails to start several services without explaining which ones. This is user unfriendly as it creates hard effort to find out what is actually wrong. There should be at least pointed out which services failed to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5389) NPE during activation of backup server in colocated replicated topology
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5389?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-5389.
-------------------------------
Fix Version/s: 10.0.0.CR4
Resolution: Done
Upstream issue ARTEMIS-243 has been fixed in artemis 1.1.0.wildfly.007
> NPE during activation of backup server in colocated replicated topology
> -----------------------------------------------------------------------
>
> Key: WFLY-5389
> URL: https://issues.jboss.org/browse/WFLY-5389
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Kalman
> Assignee: Clebert Suconic
> Fix For: 10.0.0.CR4
>
>
> I'm getting this exception when one of nodes in collocated replicated topology fails and backup is trying to get up.
> 11:41:44,643 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> 11:41:44,644 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) java.lang.NullPointerException
> 11:41:44,644 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:235)
> 11:41:44,645 ERROR [stderr] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Hoang Chuong Tran (JIRA)
Hoang Chuong Tran created JASSIST-261:
-----------------------------------------
Summary: Issue with javassist on jdk 9b112
Key: JASSIST-261
URL: https://issues.jboss.org/browse/JASSIST-261
Project: Javassist
Issue Type: Bug
Affects Versions: 3.20.0-GA
Environment: Javassist with jdk 9b112
Reporter: Hoang Chuong Tran
Assignee: Shigeru Chiba
I am migrating a project to java 9, which also uses javassist to generate runtime code.
One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
{noformat}
import static javassist.CtClass.voidType;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.HashMap;
import java.util.Map;
import org.junit.Test;
import javassist.ClassClassPath;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtField;
import javassist.CtMethod;
import javassist.CtNewMethod;
public class MyTests {
public static class MyObject {
protected Object field;
Object getField() {return field;}
public void setField(Object field) {}
}
@Test
public void test() throws InstantiationException, IllegalAccessException {
Class<? extends MyObject> clazz = compile(MyObject.class);
clazz.newInstance().setField(null);
}
/** Compile a transfer class */
public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
// Determine class setters
Map<String, Method> setters = extractSetters(targetClass);
ClassPool classPool = ClassPool.getDefault();
classPool.insertClassPath(new ClassClassPath(targetClass));
try {
// Compile a new transfer class on the fly
CtClass baseClass = classPool.get(MyObject.class.getName());
CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
for(Method originalSetter : setters.values()) {
// Create a field to hold the attribute
Class<?> fieldClass = originalSetter.getParameterTypes()[0];
CtClass fieldType = classPool.get(fieldClass.getName());
String fieldName = originalSetter.getName().substring(3);
CtField field = new CtField(fieldType, fieldName, proxyClass);
proxyClass.addField(field);
// Create a setter method to set that field
CtClass[] parameters = new CtClass[] { fieldType };
String setterBody = "{ System.out.println(\"Hello World\"); }";
CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
proxyClass.addMethod(setter);
}
Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
return javaClass;
} catch(Exception e) {
throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
}
}
/** Extract setter methods from a class */
public static Map<String, Method> extractSetters(Class<?> cls) {
Map<String, Method> setters = new HashMap<String, Method>();
for(Method method : cls.getMethods()) {
// Lookup setter methods
if(method.getName().startsWith("set")) {
// Only public setters
int modifiers = method.getModifiers();
if(Modifier.isPublic(modifiers)) {
Class<?>[] exceptions = method.getExceptionTypes();
Class<?>[] parameters = method.getParameterTypes();
Class<?> returnType = method.getReturnType();
if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
setters.put(method.getName(), method);
}
}
}
}
return setters;
}
}
{noformat}
On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
On jdk 9b112, I got the following exception
{noformat}
java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
at MyTests.compile(MyTests.java:68)
at MyTests.test(MyTests.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: javassist.NotFoundException: java.lang.Object
at javassist.ClassPool.get(ClassPool.java:450)
at MyTests.compile(MyTests.java:51)
... 24 more
{noformat}
I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBVFS-204) File system operations require both java.io.FilePermission and VirtualFilePermission
by Ivo Studensky (JIRA)
Ivo Studensky created JBVFS-204:
-----------------------------------
Summary: File system operations require both java.io.FilePermission and VirtualFilePermission
Key: JBVFS-204
URL: https://issues.jboss.org/browse/JBVFS-204
Project: JBoss VFS
Issue Type: Bug
Affects Versions: 3.2.11.Final
Reporter: Ivo Studensky
Assignee: Ivo Studensky
File system operations in org.jboss.vfs.VirtualFile check for VirtualFilePermission and then execute the particular io operation which needs java.io.FilePermission if Security Manager is enabled. Because of this a user has to duplicate each permission on a deployment for both VirtualFilePermission and FilePermission.
It should be enough to check for VirtualFilePermission and execute the io operation inside of the privileged block afterwards.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1083) Login Module is messed up when one of the module-option is empty
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1083?page=com.atlassian.jira.plugi... ]
Chen Maoqian resolved WFCORE-1083.
----------------------------------
Resolution: Done
Hi,I have reproduced the bug in WildFly 8.2.0 ,and since WildFly 9.0.0.Beta1 the bug has been fixed!
> Login Module is messed up when one of the module-option is empty
> ----------------------------------------------------------------
>
> Key: WFCORE-1083
> URL: https://issues.jboss.org/browse/WFCORE-1083
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: CentOS Linux release 7.1.1503 (Core)
> /usr/java/jdk1.8.0_45/
> WildFly 8.2.0
> Reporter: J Prasanna Venkatesan
> Assignee: Alexey Loubyansky
> Priority: Critical
>
> When one of the module-option is given as empty the whole login-module is messed up. But in real time there will be cases where the module-option can be empty. For Eg. while configuring org.jboss.security.auth.spi.LdapLoginModule, the principalDNPrefix can be empty
> *+Command with principalDNPrefix empty+*
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule33:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => ""*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true}
> +Output in standalone-full.xml+
> Wrong value is stored as principalDNPrefix
> <login-module name="org.jboss.security.auth.spi.LdapLoginModule33" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> *<module-option name="principalDNPrefix" value="principalDNSuffix"/>*
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>
> *+Command with principalDNPrefix with some value+*
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapLoginModule44:add(code=org.jboss.security.auth.spi.LdapLoginModule, flag=sufficient, module-options=[ "java.naming.provider.url" => "ldap://ldaphost.jboss.org:1", "java.naming.security.authentication" => "simple", *"principalDNPrefix" => "test"*, "principalDNSuffix" => ",ou=People,o=jboss.org", "allowEmptyPasswords" => "false", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "throwValidateError" => "true" ]){allow-resource-service-restart=true}
> +Output in standalone-full.xml+
> Values are stored correctly.
> <login-module name="org.jboss.security.auth.spi.LdapLoginModule44" code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://ldaphost.jboss.org:1"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> *<module-option name="principalDNPrefix" value="test"/>*
> <module-option name="principalDNSuffix" value=",ou=People,o=jboss.org"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6506) Session EJB no pooling in WildFly 9.0.2.final
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6506?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6506:
--------------------------------------
You need to add:
{code}
<stateless>
<bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
</stateless>
{code}
> Session EJB no pooling in WildFly 9.0.2.final
> ---------------------------------------------
>
> Key: WFLY-6506
> URL: https://issues.jboss.org/browse/WFLY-6506
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Ralph Soika
>
> After doing some perfomance tests on wildfly 9.0.2.final I recognized that stateless session ejbs are no longer pooled even if the pool settings in standalone.xml are correct. See the following example :
> {code:java}
> <subsystem xmlns="urn:jboss:domain:ejb3:3.0">
> <session-bean>
> <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="32" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> .......
> {code}
> This issue is also discussed in wildfly forum:
> https://developer.jboss.org/message/954200#954200
> In Widfly 8.0 there was the configuration missing. Now the configuration is added. But it had no effect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6506) Session EJB no pooling in WildFly 9.0.2.final
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6506?page=com.atlassian.jira.plugin.... ]
Stuart Douglas closed WFLY-6506.
--------------------------------
Resolution: Done
> Session EJB no pooling in WildFly 9.0.2.final
> ---------------------------------------------
>
> Key: WFLY-6506
> URL: https://issues.jboss.org/browse/WFLY-6506
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Ralph Soika
>
> After doing some perfomance tests on wildfly 9.0.2.final I recognized that stateless session ejbs are no longer pooled even if the pool settings in standalone.xml are correct. See the following example :
> {code:java}
> <subsystem xmlns="urn:jboss:domain:ejb3:3.0">
> <session-bean>
> <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="32" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> .......
> {code}
> This issue is also discussed in wildfly forum:
> https://developer.jboss.org/message/954200#954200
> In Widfly 8.0 there was the configuration missing. Now the configuration is added. But it had no effect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6511) Add integration test for distributed web sessions using non-tx cache
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6511:
----------------------------------
Summary: Add integration test for distributed web sessions using non-tx cache
Key: WFLY-6511
URL: https://issues.jboss.org/browse/WFLY-6511
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
We frequently encounter regressions with distributed web sessions in conjunction with a non-tx cache. We need an integration test to help catch these issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4616) Problem with distributable sessions on long IO
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4616?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-4616.
------------------------------
Resolution: Rejected
User needs to disable batching on the web session cache to allow concurrent access to session.
> Problem with distributable sessions on long IO
> ----------------------------------------------
>
> Key: WFLY-4616
> URL: https://issues.jboss.org/browse/WFLY-4616
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 10.0.0.Final
> Reporter: Paweł Goździkowski
> Assignee: Paul Ferraro
> Priority: Critical
>
> Hi,
> I faced problem with wildfly <distributable/> what I want to ask is if it will be fixed/or is fixed in new versions on wildfly.
> The problem is when server starts performing long operation, ex. moving file to ntfs file system wildfly hangs over and starts to throw exceptions.. I tested it on wildfly 8.1 and 8.2 and wildfly and problem still occures.
> Disscusion about it you can find:
> https://developer.jboss.org/message/908454?et=watches.email.thread#908454
> Exception:
> 13:19:00,670 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-19) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [j4-c64fI_msgIgF60Eqw_q72] for requestor [GlobalTransaction:<pgozdzik/web>:6832:local]! Lock held by [GlobalTransaction:<pgozdzik/web>:6830:local]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitGetKeyValueCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:226)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
>
> 13:19:00,727 ERROR [io.undertow.request] (default task-19) UT005023: Exception handling request to /test: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=6832}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> - See more at: https://developer.jboss.org/message/908454?et=watches.email.thread#908454
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years