[JBoss JIRA] (ISPN-5286) JSR-107 Support for clustered caches in HotRod implementation
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-5286?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec reassigned ISPN-5286:
-----------------------------------------
Assignee: (was: Sebastian Łaskawiec)
> JSR-107 Support for clustered caches in HotRod implementation
> --------------------------------------------------------------
>
> Key: ISPN-5286
> URL: https://issues.jboss.org/browse/ISPN-5286
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Reporter: Matej Čimbora
>
> Current implementation supports only using local caches - usage of different cache types leads to the following exceptions (when using cache which is included in configuration file):
> Client:
> {code}
> javax.cache.CacheException: ISPN021027: Failed to add local cache 'default' on the server
> at org.infinispan.jcache.remote.ServerManager$3.run(ServerManager.java:118)
> at org.infinispan.jcache.remote.ServerManager.withManagementClient(ServerManager.java:171)
> at org.infinispan.jcache.remote.ServerManager.addCache(ServerManager.java:104)
> at org.infinispan.jcache.remote.JCacheManager.create(JCacheManager.java:65)
> at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:94)
> at org.infinispan.server.test.jcache.JCacheRemoteIT.testCachingConfiguration(JCacheRemoteIT.java:78)
> {code}
> Server:
> {code}
> 10:47:29,896 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "infinispan"),
> ("cache-container" => "clustered"),
> ("local-cache" => "default")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.clustered.default.config is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> {code}
> Furthermore, when using multiple nodes in the cluster and the cache is not amongst configured caches, it is created as 'local' only on one node (this relates to fact org.infinispan.jcache.remote.ServerManager is configured to use one specific management interface - which is btw hardcoded and cannot be changed). Exception can occur when trying to write into cache.
>
> Client
> {code}
> javax.cache.CacheException: ISPN021022: Cache named 'custom' was not found.
> at org.infinispan.jcache.remote.JCacheManager.create(JCacheManager.java:75)
> at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:94)
> at org.infinispan.server.test.jcache.JCacheRemoteIT.testCachingConfiguration(JCacheRemoteIT.java:78)
> {code}
> Server
> {code}
> 10:59:01,034 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-1) ISPN005003: Exception reported: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'custom' not found amongst the configured caches
> at org.infinispan.server.hotrod.HotRodDecoder.getCache(HotRodDecoder.scala:102)
> {code}
> For full logs pease see linked BZ.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-3086) Infinite loop when creating more than two Distributed Cache nodes
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3086?page=com.atlassian.jira.plugin.... ]
Radim Vansa closed ISPN-3086.
-----------------------------
Resolution: Out of Date
This looks outdated. Please reopen if still valid with recent version.
> Infinite loop when creating more than two Distributed Cache nodes
> -----------------------------------------------------------------
>
> Key: ISPN-3086
> URL: https://issues.jboss.org/browse/ISPN-3086
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 5.3.0.Beta1
> Reporter: Balazs Zsoldos
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: cache, distribution
> Attachments: infinispan-three-nodes.zip
>
>
> I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
> I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
> *The modified XML contains:*
> <namedCache name="namedCache">
> <clustering mode="dist" />
> </namedCache>
> *The modified java code contains:*
> CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> *Symptom:*
> The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
> Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
> *BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the benefit would come out between the two topologies with more nodes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-5286) JSR-107 Support for clustered caches in HotRod implementation
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5286?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5286:
-----------------------------------
What is the state of this now when ISPN-7777 is in?
> JSR-107 Support for clustered caches in HotRod implementation
> --------------------------------------------------------------
>
> Key: ISPN-5286
> URL: https://issues.jboss.org/browse/ISPN-5286
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Reporter: Matej Čimbora
> Assignee: Sebastian Łaskawiec
>
> Current implementation supports only using local caches - usage of different cache types leads to the following exceptions (when using cache which is included in configuration file):
> Client:
> {code}
> javax.cache.CacheException: ISPN021027: Failed to add local cache 'default' on the server
> at org.infinispan.jcache.remote.ServerManager$3.run(ServerManager.java:118)
> at org.infinispan.jcache.remote.ServerManager.withManagementClient(ServerManager.java:171)
> at org.infinispan.jcache.remote.ServerManager.addCache(ServerManager.java:104)
> at org.infinispan.jcache.remote.JCacheManager.create(JCacheManager.java:65)
> at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:94)
> at org.infinispan.server.test.jcache.JCacheRemoteIT.testCachingConfiguration(JCacheRemoteIT.java:78)
> {code}
> Server:
> {code}
> 10:47:29,896 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "infinispan"),
> ("cache-container" => "clustered"),
> ("local-cache" => "default")
> ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.infinispan.clustered.default.config is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> {code}
> Furthermore, when using multiple nodes in the cluster and the cache is not amongst configured caches, it is created as 'local' only on one node (this relates to fact org.infinispan.jcache.remote.ServerManager is configured to use one specific management interface - which is btw hardcoded and cannot be changed). Exception can occur when trying to write into cache.
>
> Client
> {code}
> javax.cache.CacheException: ISPN021022: Cache named 'custom' was not found.
> at org.infinispan.jcache.remote.JCacheManager.create(JCacheManager.java:75)
> at org.infinispan.jcache.AbstractJCacheManager.createCache(AbstractJCacheManager.java:94)
> at org.infinispan.server.test.jcache.JCacheRemoteIT.testCachingConfiguration(JCacheRemoteIT.java:78)
> {code}
> Server
> {code}
> 10:59:01,034 ERROR [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-1) ISPN005003: Exception reported: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'custom' not found amongst the configured caches
> at org.infinispan.server.hotrod.HotRodDecoder.getCache(HotRodDecoder.scala:102)
> {code}
> For full logs pease see linked BZ.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-7932) JCache EntryProcesor not working for replicated cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7932?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7932:
-----------------------------------
[~mbrkic] Hi, I've tried to check the linked reproducer but it gives mode
{code}
java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test
{code}
> JCache EntryProcesor not working for replicated cache
> -----------------------------------------------------
>
> Key: ISPN-7932
> URL: https://issues.jboss.org/browse/ISPN-7932
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 9.0.1.Final
> Environment: Ubuntu Linux 4.4.0-79-generic x86_64
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> Reporter: Miljenko Brkic
> Assignee: Dan Berindei
> Attachments: jcache.tar.gz
>
>
> Cached value updated via EntryProcessor is not updated in replicated cache.
> Please find attached test application to reproduce the problem. Two instances of application increment cached value, but for one instance new value is not put in the cache (see steps to reproduce).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-7932) JCache EntryProcesor not working for replicated cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7932?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on ISPN-7932 at 1/3/18 8:54 AM:
-----------------------------------------------------------
[~mbrkic] Hi, I've tried to check the linked reproducer but it gives me
{code}
java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test
{code}
was (Author: rvansa):
[~mbrkic] Hi, I've tried to check the linked reproducer but it gives mode
{code}
java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test
{code}
> JCache EntryProcesor not working for replicated cache
> -----------------------------------------------------
>
> Key: ISPN-7932
> URL: https://issues.jboss.org/browse/ISPN-7932
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 9.0.1.Final
> Environment: Ubuntu Linux 4.4.0-79-generic x86_64
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> Reporter: Miljenko Brkic
> Assignee: Dan Berindei
> Attachments: jcache.tar.gz
>
>
> Cached value updated via EntryProcessor is not updated in replicated cache.
> Please find attached test application to reproduce the problem. Two instances of application increment cached value, but for one instance new value is not put in the cache (see steps to reproduce).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8645) infinispan-server-versions should no longer inherit from jboss-parent
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8645?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8645:
-------------------------------
Description: infinispan-server-versions should inherit from the infinispan-parent, not jboss-parent, as this will allow for less code duplication and for more dependency versions to be configured in a single place (infinispan-parent).
> infinispan-server-versions should no longer inherit from jboss-parent
> ---------------------------------------------------------------------
>
> Key: ISPN-8645
> URL: https://issues.jboss.org/browse/ISPN-8645
> Project: Infinispan
> Issue Type: Sub-task
> Components: Server
> Affects Versions: 9.2.0.Beta2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.0.CR1
>
>
> infinispan-server-versions should inherit from the infinispan-parent, not jboss-parent, as this will allow for less code duplication and for more dependency versions to be configured in a single place (infinispan-parent).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8232) Transaction inconsistency during network partitions
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8232?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8232:
------------------------------
Labels: consistency (was: )
> Transaction inconsistency during network partitions
> ---------------------------------------------------
>
> Key: ISPN-8232
> URL: https://issues.jboss.org/browse/ISPN-8232
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 9.1.0.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: consistency
>
> In scenario where the originator stays in minor partition (in our test suite, the originator isolated tests), it is possible to a transaction to be committed and rolled back in the majority partition.
> In {{Pessimitic Locking}}, the transaction is committed in one-phase using the {{PrepareCommand}}. If the partition happens when the originator sends the {{PrepareCommand}}, the nodes in the majority partition may or may not receive it. We can have the case where some nodes receive the {{PrepareCommand}} and applied and other don't receive it.
> When the topology is updated in the majority partition, the {{TransactionTable}} rollbacks all transaction in which the originator isn't present. So, in the nodes where the {{PrepareCommand}} isn't received, the transaction is rolled back.
> The originator in the minory partition detects the partition and marks the transaction partially completed. When the merge occurs, it tries to commit the transaction again. In the nodes where the transaction is rolled back, the transaction is marked as completed and when the {{PrepareCommand}} is received, it throws an {{IllegalStateException}} ({{TransactionTable:386, getOrCreateRemoteTransaction()}}). In this case, the transaction isn't removed from the {{PartitionHandlingManager}} and our test suite fails with {{"there are pending tx".}}
> Other theoretically scenario is the {{PrepareCommand}} to be executed when no locks are acquired.
> The same issue can happen with {{Optimistic Locking}} for the {{CommitCommand}}.
> The problem is the transaction table can't identify is the node left gracefully or not. A solution would be to have an {{"expected members"}} list, ideally separated from the {{CacheTopology}} to avoid sending it every time. Also, it would need some sysadmin tools for the case where the node crashes and it won't be back online for a while (or for some reason, it doesn't need to be back online).
> A sysadmin could remove the node from this list ({{CacheTopology}} is updated and there is no need to increase it) and decide what to do with the pending transactions (or an automatic mechanism to auto-commit/rollback the transaction).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8650) CLI doesn't work correctly in compatibility mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8650?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-8650:
---------------------------------------
Assignee: Gustavo Fernandes
> CLI doesn't work correctly in compatibility mode
> ------------------------------------------------
>
> Key: ISPN-8650
> URL: https://issues.jboss.org/browse/ISPN-8650
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 9.2.0.Beta2
> Reporter: Roman Macor
> Assignee: Gustavo Fernandes
>
> Steps to reproduce:
> Enable compatibility: add compatibility tag to the cache
> <compatibility enabled="true"/>
> Connect through CLI:
> [disconnected /] connect
> [standalone@localhost:9990 /] container clustered
> [standalone@localhost:9990 cache-container=clustered] cache default
> [standalone@localhost:9990 distributed-cache=default] put key value
> [standalone@localhost:9990 distributed-cache=default] encoding rest
> [standalone@localhost:9990 distributed-cache=default] get key
> [B cannot be cast to org.infinispan.remoting.MIMECacheEntry
> Server log:
> 12:12:40,438 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 4) ISPN019003: Interpreter error: java.lang.ClassCastException: [B cannot be cast to org.infinispan.remoting.MIMECacheEntry
> at org.infinispan.cli.interpreter.codec.RestCodec.decodeValue(RestCodec.java:61)
> at org.infinispan.cli.interpreter.statement.GetStatement.execute(GetStatement.java:37)
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:143)
> at org.infinispan.server.infinispan.SecurityActions$8.run(SecurityActions.java:292)
> at org.infinispan.server.infinispan.SecurityActions$8.run(SecurityActions.java:289)
> at org.infinispan.security.Security.doPrivileged(Security.java:89)
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:77)
> at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:295)
> at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:72)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:222)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 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:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (ISPN-8650) CLI doesn't work correctly in compatibility mode
by Roman Macor (JIRA)
Roman Macor created ISPN-8650:
---------------------------------
Summary: CLI doesn't work correctly in compatibility mode
Key: ISPN-8650
URL: https://issues.jboss.org/browse/ISPN-8650
Project: Infinispan
Issue Type: Bug
Components: CLI
Affects Versions: 9.2.0.Beta2
Reporter: Roman Macor
Steps to reproduce:
Enable compatibility: add compatibility tag to the cache
<compatibility enabled="true"/>
Connect through CLI:
[disconnected /] connect
[standalone@localhost:9990 /] container clustered
[standalone@localhost:9990 cache-container=clustered] cache default
[standalone@localhost:9990 distributed-cache=default] put key value
[standalone@localhost:9990 distributed-cache=default] encoding rest
[standalone@localhost:9990 distributed-cache=default] get key
[B cannot be cast to org.infinispan.remoting.MIMECacheEntry
Server log:
12:12:40,438 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 4) ISPN019003: Interpreter error: java.lang.ClassCastException: [B cannot be cast to org.infinispan.remoting.MIMECacheEntry
at org.infinispan.cli.interpreter.codec.RestCodec.decodeValue(RestCodec.java:61)
at org.infinispan.cli.interpreter.statement.GetStatement.execute(GetStatement.java:37)
at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:143)
at org.infinispan.server.infinispan.SecurityActions$8.run(SecurityActions.java:292)
at org.infinispan.server.infinispan.SecurityActions$8.run(SecurityActions.java:289)
at org.infinispan.security.Security.doPrivileged(Security.java:89)
at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:77)
at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:295)
at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:72)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:222)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
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:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months