May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4177) Upgrade server base to WildFly 8

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4177?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4177: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2579 > Upgrade server base to WildFly 8 > -------------------------------- > > Key: ISPN-4177 > URL: https://issues.jboss.org/browse/ISPN-4177 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta1, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3376) CLI upgrade command does not work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3376: ----------------------------------------------- Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 989970|https://bugzilla.redhat.com/show_bug.cgi?id=989970] from NEW to VERIFIED > CLI upgrade command does not work > --------------------------------- > > Key: ISPN-3376 > URL: https://issues.jboss.org/browse/ISPN-3376 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 6.0.0.Alpha1 > Reporter: Vitalii Chepeliuk > Assignee: Tristan Tarrant > Labels: 620, 630 > Fix For: 7.0.0.Alpha1 > > Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml > > > Run my backup server with default standalone.xml configuration > ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER > Run my new server with > ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER > 1) run command on BACKUPER > [remoting://localhost:10110/local/default]> upgrade --dumpkeys default > ISPN019502: Dumped keys for cache default > 2) run command on UPGRADER > [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default > ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source server -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3376) CLI upgrade command does not work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3376: ----------------------------------------------- Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 989970|https://bugzilla.redhat.com/show_bug.cgi?id=989970] from VERIFIED to NEW > CLI upgrade command does not work > --------------------------------- > > Key: ISPN-3376 > URL: https://issues.jboss.org/browse/ISPN-3376 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 6.0.0.Alpha1 > Reporter: Vitalii Chepeliuk > Assignee: Tristan Tarrant > Labels: 620, 630 > Fix For: 7.0.0.Alpha1 > > Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml > > > Run my backup server with default standalone.xml configuration > ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER > Run my new server with > ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER > 1) run command on BACKUPER > [remoting://localhost:10110/local/default]> upgrade --dumpkeys default > ISPN019502: Dumped keys for cache default > 2) run command on UPGRADER > [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default > ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source server -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 2.0

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3533?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3533: ----------------------------------- OK, I thought that adding a list of supported protocol versions/features into the ping response and client version auto-selection would be nice, rather than requiring to set the version in each client (the client does not need to send the list in ping request, in fact). Another topic: have you considered streaming data to and from server? It seems that it's a common request to be able to load the server via hotrod, and currently the user needs to spawn many threads in order to circumvent the put latency. > Design HotRod protocol version 2.0 > ---------------------------------- > > Key: ISPN-3533 > URL: https://issues.jboss.org/browse/ISPN-3533 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final > > > Umbrella JIRA for Hot Rod improvements for version 2.0 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4295) Include Lucene Directory in the released WildFly modules

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4295?page=com.atlassian.jira.plugin.... ] Work on ISPN-4295 started by Gustavo Fernandes. > Include Lucene Directory in the released WildFly modules > -------------------------------------------------------- > > Key: ISPN-4295 > URL: https://issues.jboss.org/browse/ISPN-4295 > Project: Infinispan > Issue Type: Feature Request > Components: Build process, Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > The Lucene Directory module for WildFly should be included in the other released WildFly modules, and also we need integration tests for it. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 2.0

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3533?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3533: ---------------------------------------- Sounds a bit over engineered. The server is easier to upgrade the clients, since a single server could be serving hundreds or thousands of clients, hence you are more likely to encounter the situation where the server is newer than the client, and that we support very well. However, it's not very often you find clients talking to older servers, and even then, they can easily set a different version of the protocol to use. > Design HotRod protocol version 2.0 > ---------------------------------- > > Key: ISPN-3533 > URL: https://issues.jboss.org/browse/ISPN-3533 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final > > > Umbrella JIRA for Hot Rod improvements for version 2.0 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 2.0

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3533?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3533: ----------------------------------- Fix Version/s: 7.0.0.Final > Design HotRod protocol version 2.0 > ---------------------------------- > > Key: ISPN-3533 > URL: https://issues.jboss.org/browse/ISPN-3533 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Final > > > Umbrella JIRA for Hot Rod improvements for version 2.0 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2956: ---------------------------------------- I've been looking into this last week trying to come up with a solution that would make these kind of operations reliable. For that, a change of protocol is required and as we near the completion of Hot Rod 2.0 version, it's probably a good time to address this. To support these kind of use cases, Hot Rod needs to move from the server producing the entry's version, to having the Hot Rod clients produce the version information and shipping it along with each modification. If the operation fails and the client receives the failure, it would be able to retry the operation. The retry would essentially involve sending the same operation, with a new message ID and a new RETRY flag. When the server receives a retry operation, it would check whether the entry is already present in the cache (cluster-wide), and check if the version provided by the client is the same as the entry in memory. If it's not, in the case of putIfAbsent, it would mean that entry has been overriden by someone else since the retry, and putIfAbsent would just return false. It would be the responsibility of the Hot Rod client implementations to generate the version and hence it would be transparent for the Hot Rod users. All operations making modifications, except clear, would ship the version to be applied with the entry, and operations such as replaceIfUnmodified would ship both, the version to compare the entry with, and the version to be used if the replace succeeds. Even operations such as put() would need to ship to the server the version because if the clients provide the flag to force to return the previous value, they need to provide atomicity guarantees. > putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract > ------------------------------------------------------------------- > > Key: ISPN-2956 > URL: https://issues.jboss.org/browse/ISPN-2956 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > Labels: hotrod-java-client, remote-clients > Fix For: 7.0.0.Beta1 > > > Hot Rod's putIfAbsent might have issues on some edge cases: > {quote}I want to know whether the putting entry already exists in the remote > cache cluster, or not. > I thought that RemoteCache.putIfAbsent() would be useful for that > purpose, i.e., > {code} > if (remoteCache.putIfAbsent(k,v) == null) { > // new entry. > } else { > // k already exists. > } > {code} > But no. > The putIfAbsent() for new entry may return non-null value, if one of the > server crushed while putting. > The behavior is like the following: > 1. Client do putIfAbsent(k,v). > 2. The server receives the request and sends replication requests to > other servers. If the server crushed before completing replication, some > servers own that (k,v), but others not. > 3. Client receives the error. The putIfAbsent() internally retries the > same request to the next server in the cluster server list. > 4. If the next server owns the (k,v), the putIfAbsent() returns the > replicated (k,v) at the step 2, without any error. > So, putIfAbsent() is not reliable for knowing whether the putting entry > is *exactly* new or not. > Does anyone have any idea/workaround for this purpose?{quote} > A workaround is to do this: > {quote}We got a simple solution, which can be applied to our customer's application. > If each value part of putting (k,v) is unique or contains unique value, > the client can do *double check* wether the entry is new. > {code} > val = System.nanoTime(); // or uuid is also useful. > if ((ret = cache.putIfAbsent(key, val)) == null > || ret.equals(val)) { > // new entry, if the return value is just the same. > } else { > // key already exists. > } > {code} > We are proposing this workaround which almost works fine.{quote} > However, this is a bit of a cludge. > Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4307) RHQ JMX plugin failed to get measurement values

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4307?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4307: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1099864 > RHQ JMX plugin failed to get measurement values > ----------------------------------------------- > > Key: ISPN-4307 > URL: https://issues.jboss.org/browse/ISPN-4307 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: William Burns > > We are not able to monitor cache statistics due to this error. RHQ agents are reporting: > 2014-05-21 05:54:24,958 WARN [MeasurementManager.collector-1] (rhq.core.pc.measurement.MeasurementCollectorRunner)- Failure to collect measurement data for Resource[id=10774, uuid=9f67384f-8f53-4a25-a138-13c54b32c6df, type={Infinispan}Infinispan Cache, key="___default(dist_sync)", name=___default(dist_sync), parent=DefaultCacheManager] - cause: java.lang.NullPointerException:null > 2014-05-21 05:55:32,013 ERROR [WorkerThread#1[10.16.23.98:59988]] (rhq.core.pc.measurement.MeasurementManager)- Could not get measurement values > java.lang.NullPointerException > at org.rhq.plugins.jmx.MBeanResourceComponent.getEmsConnection(MBeanResourceComponent.java:574) > at org.infinispan.rhq.CacheComponent.getValues(CacheComponent.java:97) > at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocation.call(ResourceContainer.java:654) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4324) QueryAuthorizationTest.createBeforeClass -- fail to authenticate on Windows

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4324?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4324: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1101247|https://bugzilla.redhat.com/show_bug.cgi?id=1101247] from NEW to CLOSED > QueryAuthorizationTest.createBeforeClass -- fail to authenticate on Windows > --------------------------------------------------------------------------- > > Key: ISPN-4324 > URL: https://issues.jboss.org/browse/ISPN-4324 > Project: Infinispan > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Alpha4 > Environment: All Windows environments and all JDKs are affected by this issue. > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Labels: testsuite_stability, windows > > Test is failing in createBeforeClass method during cache manager creation. Authentication fails. Note that this issue is NOT present on RHEL environment. This is Windows specific and prevents actual test method from running and proceeding. > java.security.AccessControlException: access denied (javax.security.auth.AuthPermission doAs) > at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374) > at java.security.AccessController.checkPermission(AccessController.java:549) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at javax.security.auth.Subject.doAs(Subject.java:326) > at org.infinispan.security.QueryAuthorizationTest.createCacheManager(QueryAuthorizationTest.java:44) > at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:31) > at org.infinispan.test.SingleCacheManagerTest.createBeforeClass(SingleCacheManagerTest.java:44) > 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138) > at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014