[JBoss JIRA] (ISPN-3323) Update Hotrod client version number
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3323?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3323:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> made a comment on [bug 987526|https://bugzilla.redhat.com/show_bug.cgi?id=987526]
Please see the linked JIRA.
> Update Hotrod client version number
> -----------------------------------
>
> Key: ISPN-3323
> URL: https://issues.jboss.org/browse/ISPN-3323
> Project: Infinispan
> Issue Type: Task
> Components: Remote protocols
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
>
> {{BasicCache.getVersion()}} is documented to return "the version of Infinispan", but {{RemoteCacheImpl.getVersion()}} returns {{Version.getProtocolVersion()}} (which is {{"1.0"}}).
> I think there should be a separate method to return the protocol version, and {{RemoteCacheImpl.getVersion()}} should return the Infinispan version (with a hook in the release script to update it automatically).
> {{Version.getProtocolVersion()}} should also be updated to {{"1.2"}}.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3323) Update Hotrod client version number
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3323?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3323:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=987526
> Update Hotrod client version number
> -----------------------------------
>
> Key: ISPN-3323
> URL: https://issues.jboss.org/browse/ISPN-3323
> Project: Infinispan
> Issue Type: Task
> Components: Remote protocols
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
>
> {{BasicCache.getVersion()}} is documented to return "the version of Infinispan", but {{RemoteCacheImpl.getVersion()}} returns {{Version.getProtocolVersion()}} (which is {{"1.0"}}).
> I think there should be a separate method to return the protocol version, and {{RemoteCacheImpl.getVersion()}} should return the Infinispan version (with a hook in the release script to update it automatically).
> {{Version.getProtocolVersion()}} should also be updated to {{"1.2"}}.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3330:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=987524
> Hotrod clients getWithMetadata doesn't work with dist/repl cache
> ----------------------------------------------------------------
>
> Key: ISPN-3330
> URL: https://issues.jboss.org/browse/ISPN-3330
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> I have a cluster of 2 infinispan servers with this configuration:
> {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000">
> <locking isolation="REPEATABLE_READ"/>
> </distributed-cache>
> </cache-container>
> </subsystem>{code}
> Running this code:
> {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan
> MetadataValue<String> k1 = remoteCache.getWithMetadata("k1");
> assertTrue(k1.getValue().equals("v1"));
> // microseconds converted to seconds
> assertTrue(k1.getLifespan() == 10);
> assertTrue(k1.getMaxIdle() == -1);{code}
> fails with:
> {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can
> not be cast to org.infinispan.container.entries.InternalCacheEntry
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code}
> Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3330:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> made a comment on [bug 987524|https://bugzilla.redhat.com/show_bug.cgi?id=987524]
Please see the linked JIRA for more information.
> Hotrod clients getWithMetadata doesn't work with dist/repl cache
> ----------------------------------------------------------------
>
> Key: ISPN-3330
> URL: https://issues.jboss.org/browse/ISPN-3330
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 6.0.0.Final
>
>
> I have a cluster of 2 infinispan servers with this configuration:
> {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000">
> <locking isolation="REPEATABLE_READ"/>
> </distributed-cache>
> </cache-container>
> </subsystem>{code}
> Running this code:
> {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan
> MetadataValue<String> k1 = remoteCache.getWithMetadata("k1");
> assertTrue(k1.getValue().equals("v1"));
> // microseconds converted to seconds
> assertTrue(k1.getLifespan() == 10);
> assertTrue(k1.getMaxIdle() == -1);{code}
> fails with:
> {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can
> not be cast to org.infinispan.container.entries.InternalCacheEntry
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code}
> Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3298) Can't retrieve evicted entries from FileCacheStore
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3298?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3298:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=987521
> Can't retrieve evicted entries from FileCacheStore
> --------------------------------------------------
>
> Key: ISPN-3298
> URL: https://issues.jboss.org/browse/ISPN-3298
> Project: Infinispan
> Issue Type: Bug
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Attachments: server.log
>
>
> When using this configuration for the latest (6.0.0-SNAPSHOT) infinispan-server:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="local">
> <cache-container name="local" default-cache="default">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <eviction strategy="LRU" max-entries="5"/>
> <file-store passivation="true" path="dc" purge="true" shared="false"/>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> and running this code:
> {code}
> for (int i = 0; i < 6; i++) {
> cache.put("k" + i, "v" + i);
> }
> for (int i = 0; i < 6; i++) {
> System.out.println("k" + i + ": " + cache.get("k" + i));
> }
> {code}
> I'm getting (reproducibly):
> {quote}
> k0: null
> k1: v1
> k2: v2
> k3: null
> k4: v4
> k5: v5
> {quote}
> The directory $\{server\}/standalone/data/dc/default/ contains 2 files (with v0 and v3).
> Server trace log attached.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3298) Can't retrieve evicted entries from FileCacheStore
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3298?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3298:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> made a comment on [bug 987521|https://bugzilla.redhat.com/show_bug.cgi?id=987521]
Please see the linked JIRA for more information.
> Can't retrieve evicted entries from FileCacheStore
> --------------------------------------------------
>
> Key: ISPN-3298
> URL: https://issues.jboss.org/browse/ISPN-3298
> Project: Infinispan
> Issue Type: Bug
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Attachments: server.log
>
>
> When using this configuration for the latest (6.0.0-SNAPSHOT) infinispan-server:
> {code:xml}
> <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="local">
> <cache-container name="local" default-cache="default">
> <local-cache name="default" start="EAGER">
> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <eviction strategy="LRU" max-entries="5"/>
> <file-store passivation="true" path="dc" purge="true" shared="false"/>
> </local-cache>
> </cache-container>
> </subsystem>
> {code}
> and running this code:
> {code}
> for (int i = 0; i < 6; i++) {
> cache.put("k" + i, "v" + i);
> }
> for (int i = 0; i < 6; i++) {
> System.out.println("k" + i + ": " + cache.get("k" + i));
> }
> {code}
> I'm getting (reproducibly):
> {quote}
> k0: null
> k1: v1
> k2: v2
> k3: null
> k4: v4
> k5: v5
> {quote}
> The directory $\{server\}/standalone/data/dc/default/ contains 2 files (with v0 and v3).
> Server trace log attached.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3293) Putting entries with memcached is ignoring the queue-flush-interval parameter
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3293?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3293:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=987520
> Putting entries with memcached is ignoring the queue-flush-interval parameter
> -----------------------------------------------------------------------------
>
> Key: ISPN-3293
> URL: https://issues.jboss.org/browse/ISPN-3293
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jakub Markos
> Assignee: Tristan Tarrant
> Attachments: server1.log, server2.log
>
>
> I have a cluster of 2 nodes with the following configuration:
> {code:xml}
> <replicated-cache name="memcachedCache"
> start="EAGER"
> mode="ASYNC"
> batching="false"
> queue-size="1000"
> queue-flush-interval="15000">
> </replicated-cache>
> {code}
> The following code (MemcachedHelper is a memcached client)
> {code}
> mc1 = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint().getPort());
> mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint().getPort());
> mc1.set("key1", "value1");
> assertTrue(null != mc1.get("key1"));
> assertTrue(null == mc2.get("key1"));
> {code}
> fails on the 2nd assert, because the entry is retrieved.
> According to logs (attached), the replication queue is correctly flushed after 15 seconds with 1 element (and happens after the gets).
> Works correctly with hotrod (entry is replicated only after the flush happens).
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3293) Putting entries with memcached is ignoring the queue-flush-interval parameter
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3293?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3293:
-----------------------------------------------
Jakub Markos <jmarkos(a)redhat.com> made a comment on [bug 987520|https://bugzilla.redhat.com/show_bug.cgi?id=987520]
Please see the linked JIRA for more information.
> Putting entries with memcached is ignoring the queue-flush-interval parameter
> -----------------------------------------------------------------------------
>
> Key: ISPN-3293
> URL: https://issues.jboss.org/browse/ISPN-3293
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jakub Markos
> Assignee: Tristan Tarrant
> Attachments: server1.log, server2.log
>
>
> I have a cluster of 2 nodes with the following configuration:
> {code:xml}
> <replicated-cache name="memcachedCache"
> start="EAGER"
> mode="ASYNC"
> batching="false"
> queue-size="1000"
> queue-flush-interval="15000">
> </replicated-cache>
> {code}
> The following code (MemcachedHelper is a memcached client)
> {code}
> mc1 = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint().getPort());
> mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint().getPort());
> mc1.set("key1", "value1");
> assertTrue(null != mc1.get("key1"));
> assertTrue(null == mc2.get("key1"));
> {code}
> fails on the 2nd assert, because the entry is retrieved.
> According to logs (attached), the replication queue is correctly flushed after 15 seconds with 1 element (and happens after the gets).
> Works correctly with hotrod (entry is replicated only after the flush happens).
--
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
11 years, 2 months