[JBoss JIRA] (ISPN-3709) ClusteredCacheTest.testPutForExternalRead is failing randomly
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3709:
---------------------------------
Summary: ClusteredCacheTest.testPutForExternalRead is failing randomly
Key: ISPN-3709
URL: https://issues.jboss.org/browse/ISPN-3709
Project: Infinispan
Issue Type: Bug
Affects Versions: 6.0.0.CR1
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 6.0.0.Final
some subclasses are failing with:
{code}
java.lang.AssertionError: expected:<4> but was:<3>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.infinispan.query.blackbox.ClusteredCacheTest.testPutForExternalRead(ClusteredCacheTest.java:296)
{code}
--
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, 5 months
[JBoss JIRA] (ISPN-3697) Improved lifecycle control of JGroupsChannelLookup
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3697?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3697:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2210, https://github.com/infinispan/infinispan-server/pull/185 (was: https://github.com/infinispan/infinispan/pull/2210)
> Improved lifecycle control of JGroupsChannelLookup
> --------------------------------------------------
>
> Key: ISPN-3697
> URL: https://issues.jboss.org/browse/ISPN-3697
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 6.0.0.Final
>
>
> Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel.
> In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not, e.g.
> https://issues.jboss.org/browse/WFLY-2458
> To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close().
> So what I propose is the following:
> boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect".
> boolean shouldDisconnect();
> boolean shouldClose();
--
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, 5 months
[JBoss JIRA] (ISPN-3534) Investigate performance regressions in Infinispan 6.0.0
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3534?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3534:
-------------------------------
Status: Pull Request Sent (was: Pull Request Sent)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2219, https://github.com/infinispan/infinispan-server/pull/184 (was: https://github.com/infinispan/infinispan/pull/2219)
> Investigate performance regressions in Infinispan 6.0.0
> -------------------------------------------------------
>
> Key: ISPN-3534
> URL: https://issues.jboss.org/browse/ISPN-3534
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> As per QE:
> 30% performance regression in distributed, udp, tx, async library stress tests
> 20% performance regression in distributed, udp, tx, sync library stress tests
> 20% performance regression in memcached client stress tests
> 50%+ performance regression in REST client stress
> tests
--
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, 5 months
[JBoss JIRA] (ISPN-3708) The HotRod endpoint in Server doesn't return the cache set as default in the container configuration
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-3708:
-------------------------------------
Summary: The HotRod endpoint in Server doesn't return the cache set as default in the container configuration
Key: ISPN-3708
URL: https://issues.jboss.org/browse/ISPN-3708
Project: Infinispan
Issue Type: Bug
Components: Remote protocols, Server
Affects Versions: 6.0.0.CR1
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 6.0.0.Final
The HotRod protocol defines that when a client requests a cache using an empty name ("") it should return the default cache. In embedded mode this is defined by a constant, but in server mode the default cache can be set in the container configuration. The HotRod server should allow setting a different cache to use as default
--
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, 5 months
[JBoss JIRA] (ISPN-3694) ActivationInterceptor when activating an entry has a gap when no entry is available
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3694?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3694:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ActivationInterceptor when activating an entry has a gap when no entry is available
> -----------------------------------------------------------------------------------
>
> Key: ISPN-3694
> URL: https://issues.jboss.org/browse/ISPN-3694
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.CR2
>
>
> The ActivationInterceptor currently attempts to remove entries from the cache store during the invocation of a get. However the actual committing of the data to the Data Container doesn't occur until the EntryWrappingInterceptor (non-tx) or when the CommitCommand (tx) is invoked, both of which is after the entry is removed from the loader. This can cause a momentary lapse where the entry is no longer in the data container or the loader. Also if you rolled back the tx containing the activation you would lose the entry completely.
--
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, 5 months
[JBoss JIRA] (ISPN-3694) ActivationInterceptor when activating an entry has a gap when no entry is available
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3694?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3694:
-------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR2)
> ActivationInterceptor when activating an entry has a gap when no entry is available
> -----------------------------------------------------------------------------------
>
> Key: ISPN-3694
> URL: https://issues.jboss.org/browse/ISPN-3694
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 6.0.0.Final
>
>
> The ActivationInterceptor currently attempts to remove entries from the cache store during the invocation of a get. However the actual committing of the data to the Data Container doesn't occur until the EntryWrappingInterceptor (non-tx) or when the CommitCommand (tx) is invoked, both of which is after the entry is removed from the loader. This can cause a momentary lapse where the entry is no longer in the data container or the loader. Also if you rolled back the tx containing the activation you would lose the entry completely.
--
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, 5 months
[JBoss JIRA] (ISPN-3534) Investigate performance regressions in Infinispan 6.0.0
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3534?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3534:
--------------------------------------
OK, cool, I'll retry with UFC.max_credits=2m
The 6.1.0.GA test execution was with 200k value as well
(for earlier tests that don't have certain properties recorded, it's possible to read some of them from the configs that you can find in the Attachments tab of the test execution page:
http://jawa36.mw.lab.eng.brq.redhat.com:8080/repo/exec/640 (the execution 6.1.0.GA 2)
http://jawa36.mw.lab.eng.brq.redhat.com:8080/repo/rest/testExecution/atta... (direct link to the attachment)
> Investigate performance regressions in Infinispan 6.0.0
> -------------------------------------------------------
>
> Key: ISPN-3534
> URL: https://issues.jboss.org/browse/ISPN-3534
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> As per QE:
> 30% performance regression in distributed, udp, tx, async library stress tests
> 20% performance regression in distributed, udp, tx, sync library stress tests
> 20% performance regression in memcached client stress tests
> 50%+ performance regression in REST client stress
> tests
--
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, 5 months
[JBoss JIRA] (ISPN-3534) Investigate performance regressions in Infinispan 6.0.0
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3534?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3534:
------------------------------------
[~mlinhard], the old bundler was only a part of the issue. We also noticed that setting {{UFC.max_credits=200k}} slows things down (maybe more so with Infinispan 6.0 than 5.2).
I see in the comparison you posted that the JDG 6.2 snapshots both ran with 200k, could you run the test again with 2m? And can you find the max_credits value in the JDG 6.1 run?
> Investigate performance regressions in Infinispan 6.0.0
> -------------------------------------------------------
>
> Key: ISPN-3534
> URL: https://issues.jboss.org/browse/ISPN-3534
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> As per QE:
> 30% performance regression in distributed, udp, tx, async library stress tests
> 20% performance regression in distributed, udp, tx, sync library stress tests
> 20% performance regression in memcached client stress tests
> 50%+ performance regression in REST client stress
> tests
--
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, 5 months
[JBoss JIRA] (ISPN-3707) I tried to access mbeans on a remotely running Jboss AS7 infinispan server using the jconsole.bat from the infinispan Jboss AS7 installation and i am gettign the following error:
by Pra remo (JIRA)
Pra remo created ISPN-3707:
------------------------------
Summary: I tried to access mbeans on a remotely running Jboss AS7 infinispan server using the jconsole.bat from the infinispan Jboss AS7 installation and i am gettign the following error:
Key: ISPN-3707
URL: https://issues.jboss.org/browse/ISPN-3707
Project: Infinispan
Issue Type: Bug
Reporter: Pra remo
Assignee: Mircea Markus
I tried to access mbeans on a remotely running Jboss AS7 infinispan server using the jconsole.bat from the infinispan Jboss AS7 installation and i am gettign the following error:
xception in thread "VMPanel.connect" java.lang.NoClassDefFoundError: org/jboss/logging/Logger
at org.jboss.remotingjmx.RemotingConnectorProvider.<clinit>(RemotingConnectorProvider.java:42)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at com.sun.jmx.remote.util.Service$LazyIterator.next(Service.java:270)
at javax.management.remote.JMXConnectorFactory.getConnectorAsService(JMXConnectorFactory.java:425)
at javax.management.remote.JMXConnectorFactory.newJMXConnector(JMXConnectorFactory.java:310)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:247)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:207)
at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:336)
at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:296)
at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:280)
Caused by: java.lang.ClassNotFoundException: org.jboss.logging.Logger
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 11 more
I used both url's : service:jmx:remoting-jmx://:9999 service:jmx:remoting-jmx://:4447
C:\Developer\JDK\Java\jdk1.6.0_34\lib\jconsole.jar;C:\Developer\JDK\Java\jdk1.6.0_34\lib\tools.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infini
span-server-6.0.0.CR1\jboss-modules.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infinispan-server-6.0.0.CR1\modules\system\layers\base\org\jboss\
remoting-jmx\main\remoting-jmx-1.1.0.Final.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infinispan-server-6.0.0.CR1\modules\system\layers\base\org
\jboss\staxmapper\main\staxmapper-1.1.0.Final.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infinispan-server-6.0.0.CR1\modules\system\layers\base\
org\jboss\as\protocol\main\jboss-as-protocol-7.2.0.Final.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infinispan-server-6.0.0.CR1\modules\system\l
ayers\base\org\jboss\dmr\main\jboss-dmr-1.1.6.Final.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infinispan-server-6.0.0.CR1\modules\system\layers
\base\org\jboss\as\controller-client\main\jboss-as-controller-client-7.2.0.Final.jar;C:\Users\<user>\Downloads\infinispan-server-6.0.0.CR1-bin\infinispan-server-6.
0.0.CR1\modules\system\layers\base\org\jboss\threads\main\jboss-threads-2.1.0.Fin
--
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, 5 months