[JBoss JIRA] (ISPN-3895) Compilation with Java 1.6.0_65 fails
by Valerio Schiavoni (JIRA)
Valerio Schiavoni created ISPN-3895:
---------------------------------------
Summary: Compilation with Java 1.6.0_65 fails
Key: ISPN-3895
URL: https://issues.jboss.org/browse/ISPN-3895
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.Final
Reporter: Valerio Schiavoni
Assignee: Mircea Markus
I'm trying to follow the 'Getting started with Infinispan' as published here:
http://infinispan.org/docs/6.0.x/getting_started/getting_started.html
There, it is specified: "A Java 6.0 JDK"
Compiling INFINISPAN-6.0.0-Final with Maven 3.1.1 and java version "1.6.0_65, the maven-enforcer-plugin complains:
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce' with basic configurator -->
[DEBUG] (s) fail = true
[DEBUG] (s) failFast = false
[DEBUG] (f) ignoreCache = false
[DEBUG] (s) project = MavenProject: org.infinispan:infinispan-parent:7.0.0-SNAPSHOT @ /Users/veleno/workspace-git/infinispan/parent/pom.xml
[DEBUG] (s) version = [1.7,)
[DEBUG] (s) version = [3.0.3,)
[DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireJavaVersion@15194a34, org.apache.maven.plugins.enforcer.RequireMavenVersion@2f56a6be]
[DEBUG] (s) session = org.apache.maven.execution.MavenSession@7b681460
[DEBUG] (s) skip = false
[DEBUG] -- end configuration --
[DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireJavaVersion
[DEBUG] Rule org.apache.maven.plugins.enforcer.RequireJavaVersion is cacheable.
[DEBUG] Detected Java String: 1.6.0_65
[DEBUG] Normalized Java String: 1.6.0-65
[DEBUG] Parsed Version: Major: 1 Minor: 6 Incremental: 0 Build: 65 Qualifier: null
[DEBUG] Adding failure due to exception
org.apache.maven.enforcer.rule.api.EnforcerRuleException: Detected JDK Version: 1.6.0-65 is not in the allowed range [1.7,).
at org.apache.maven.plugins.enforcer.AbstractVersionEnforcer.enforceVersion(AbstractVersionEnforcer.java:101)
at org.apache.maven.plugins.enforcer.RequireJavaVersion.execute(RequireJavaVersion.java:65)
at org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:186)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
$java -version:
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam updated ISPN-3894:
--------------------------------
Attachment: CoalesceEntries.java
Please see the attachment CoalesceEntries.java containing a sample program to demonstrate the file size of the store.
Please use this to measure against the original implementation.
Here are the results on my machine:
Original implementation filesize trend (in bytes):
File size: 55004
File size: 4510204
File size: 13365404
File size: 26620604
File size: 44275804
File size: 66331004
File size: 92786204
File size: 123641404
File size: 158896604
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
File size: 198551804
With the proposed fix:
File size: 55004
File size: 4510204
File size: 13321128
File size: 22135836
File size: 31051712
File size: 39873792
File size: 48736284
File size: 79591484
File size: 92812184
File size: 92812184
File size: 61785872
File size: 4510204
File size: 13321128
File size: 22135836
File size: 31051712
File size: 39873792
File size: 65006232
File size: 79508176
File size: 79508176
File size: 75257128
File size: 75257128
File size: 4510204
File size: 13321128
File size: 22135836
File size: 31051712
File size: 47923940
File size: 66310304
File size: 72789896
File size: 72789896
File size: 75216636
File size: 75216636
File size: 13934324
File size: 13310404
File size: 22125112
File size: 35543064
File size: 53076948
File size: 66304548
File size: 66304548
File size: 66397356
File size: 74923224
File size: 74923224
File size: 4510204
> SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
> ----------------------------------------------------------------------------------
>
> Key: ISPN-3894
> URL: https://issues.jboss.org/browse/ISPN-3894
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2
> Reporter: Rajesh Jangam
> Assignee: Mircea Markus
> Attachments: CoalesceEntries.java
>
>
> This issue is related to issue ISPN-3877.
> Here we have a use case where the size of the entries gradually keeps on increasing and then finally those entries expire.
> 1. Smaller entries expire and new bigger entries start getting added
> 2. These new bigger entries will not fit into the free slots (entries) created due to the expiry of smaller entries.
> 3. Thus, these new bigger entries only get allocated at the end of the file resulting in growth of file size.
> The optimization proposed is to:
> 1. Coalesce/Combine adjacent free entries during the periodic purge cycle to create bigger/larger free entries.
> 2. While allocating from an existing free entry, check if the size of the free entry is more than required for the new request being allocated. If yes, then, split the free entry into two free entries:
> a. First part equal to the length being requested
> This is returned as a part of the allocation activity.
> b. Second part equal to the remainder of the space.
> This added back as a free entry to the freeList.
> Thus free space created due to expiry of smaller entries becomes available for consumption for the larger entries to some extent.
> This reduces file size of the store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam commented on ISPN-3877:
-------------------------------------
Another related issue ISPN-3894 is created as well.
> SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Galder Zamarreño
> Attachments: PersistentQueue.java
>
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
by Rajesh Jangam (JIRA)
Rajesh Jangam created ISPN-3894:
-----------------------------------
Summary: SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
Key: ISPN-3894
URL: https://issues.jboss.org/browse/ISPN-3894
Project: Infinispan
Issue Type: Patch
Components: Loaders and Stores
Affects Versions: 6.0.0.Final
Environment: Oracle JDK 1.7, Windows Server 2008 R2
Reporter: Rajesh Jangam
Assignee: Mircea Markus
This issue is related to issue ISPN-3877.
Here we have a use case where the size of the entries gradually keeps on increasing and then finally those entries expire.
1. Smaller entries expire and new bigger entries start getting added
2. These new bigger entries will not fit into the free slots (entries) created due to the expiry of smaller entries.
3. Thus, these new bigger entries only get allocated at the end of the file resulting in growth of file size.
The optimization proposed is to:
1. Coalesce/Combine adjacent free entries during the periodic purge cycle to create bigger/larger free entries.
2. While allocating from an existing free entry, check if the size of the free entry is more than required for the new request being allocated. If yes, then, split the free entry into two free entries:
a. First part equal to the length being requested
This is returned as a part of the allocation activity.
b. Second part equal to the remainder of the space.
This added back as a free entry to the freeList.
Thus free space created due to expiry of smaller entries becomes available for consumption for the larger entries to some extent.
This reduces file size of the store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam commented on ISPN-3877:
-------------------------------------
Hello Mircea,
Thanks for your response. I have attached a small test program that can show the difference in the space usage.
On my machine,
a. with the original SingleFileStore version, the disk consumption reaches to around 10-11 MB and stays there.
b. with the modified (patched version), the disk consumption reaches to around 10-11MB, but after the purge cycles kick-in, the file size remains below 500KB consistently.
I am going to attach a pull request for this issue. So, please review the diff from there.
After your review, can you also please let me know if this enhancement seems ok from your point of view?
The overhead on the purge cycle because of our truncation logic is very minimal (around few tens of milli-seconds).
Also, I am going to create another JIRA issue for another enhancement related to coalescing adjacent free entries.
Thanks,
Rajesh
> SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Galder Zamarreño
> Attachments: PersistentQueue.java
>
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam updated ISPN-3877:
--------------------------------
Attachment: PersistentQueue.java
This is a test program that can demonstrate the difference in file usage when the vanilla SingleFileStore version is used versus the patched version
> SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Galder Zamarreño
> Attachments: PersistentQueue.java
>
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam updated ISPN-3877:
--------------------------------
Summary: SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem (was: Disk Space optimizations for SingleFileStore)
Description:
We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
We tend to create a lot of entries in the store and remove them when not required.
However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
was:
We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
We tend to create a lot of entries in the store and remove them when not required.
However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
The proposed fix is twofold:
1. Truncates the file if there are free fileentries at the end of the data file.
2. Coalesces consecutive free fileentries into one so that the probability of finding a free file entry capable enough to contain a newly added key-value pair increases.
Please review this diff and let us know your opinion
> SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Galder Zamarreño
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (ISPN-3873) Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3873:
------------------------------------
Correction: actually we do look at the topology id of the command wrapped in the SingleRpcCommand, the problem is that the topology id is never set for InvalidateCommands.
There are two places where we could set the topology id: in StateTransferInterceptor (which doesn't do anything ATM because we don't forward InvalidateCommands during state transfer), and/or in RpcManagerImpl (which also doesn't do anything because the command was already wrapped in a SingleRpcCommand by the time we try to set the topology id).
> Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3873
> URL: https://issues.jboss.org/browse/ISPN-3873
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.1.Final
> Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45
> Reporter: Karl von Randow
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha1
>
> Attachments: infinispan.trace.gz
>
>
> Sometimes when I start one server in a cluster I see the NullPointerException reproduced below. This only occurs if there is another server running. I run multiple caches with clustering using invalidation. JGroups using JDBC_PING and TCP. The caches are non-transactional.
> The NPE is because the keyEq (Equivalence instance for keys) is null. I believe this is because the command is processed before the start() method has been called on the AbstractInvocationContextFactory, as the start() method sets the keyEq ivar.
> At this point I'm not sure how to fix it!
> java.lang.NullPointerException
> at org.infinispan.commons.equivalence.EquivalentHashMap.put(EquivalentHashMap.java:176)
> at org.infinispan.commons.equivalence.EquivalentHashSet.add(EquivalentHashSet.java:109)
> at org.infinispan.context.impl.NonTxInvocationContext.addLockedKey(NonTxInvocationContext.java:84)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:190)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> 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.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:186)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:84)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:259)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:211)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.JChannel.up(JChannel.java:730)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1019)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.RSVP.up(RSVP.java:221)
> at org.jgroups.protocols.UNICAST2.removeAndPassUp(UNICAST2.java:919)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:800)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:415)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD.up(FD.java:255)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1399)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months