[JBoss JIRA] (ISPN-3436) Not working RemoteManager.getBulk() and keySet() in compatibility mode
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3436?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3436:
--------------------------------
Affects Version/s: 6.0.0.Alpha3
> Not working RemoteManager.getBulk() and keySet() in compatibility mode
> ----------------------------------------------------------------------
>
> Key: ISPN-3436
> URL: https://issues.jboss.org/browse/ISPN-3436
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
>
> When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
> {code:borderStyle=solid}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
> 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)
> ...
> {code}
> Code that did it:
> {code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
> public void testEmbeddedPutHotRodGetBulk() {
> Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
> RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
> populateCacheManager(embedded);
> Map<Integer, Integer> get = remote.getBulk();
> assertEquals(100, get.size());
> for(int i = 0; i < 100; i++) {
> assertTrue(get.containsValue(i));
> assertTrue(get.containsKey(i));
> }
> }
> {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, 7 months
[JBoss JIRA] (ISPN-3436) Not working RemoteManager.getBulk() and keySet() in compatibility mode
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3436?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3436:
--------------------------------
Fix Version/s: 6.0.0.Final
> Not working RemoteManager.getBulk() and keySet() in compatibility mode
> ----------------------------------------------------------------------
>
> Key: ISPN-3436
> URL: https://issues.jboss.org/browse/ISPN-3436
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
> {code:borderStyle=solid}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
> 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)
> ...
> {code}
> Code that did it:
> {code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
> public void testEmbeddedPutHotRodGetBulk() {
> Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
> RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
> populateCacheManager(embedded);
> Map<Integer, Integer> get = remote.getBulk();
> assertEquals(100, get.size());
> for(int i = 0; i < 100; i++) {
> assertTrue(get.containsValue(i));
> assertTrue(get.containsKey(i));
> }
> }
> {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, 7 months
[JBoss JIRA] (ISPN-3436) Not working RemoteManager.getBulk() and keySet() in compatibility mode
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3436:
---------------------------------
Summary: Not working RemoteManager.getBulk() and keySet() in compatibility mode
Key: ISPN-3436
URL: https://issues.jboss.org/browse/ISPN-3436
Project: Infinispan
Issue Type: Bug
Components: Remote protocols
Reporter: Jiří Holuša
Assignee: Galder Zamarreño
When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
{code:borderStyle=solid}
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
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)
...
{code}
Code that did it:
{code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
public void testEmbeddedPutHotRodGetBulk() {
Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
populateCacheManager(embedded);
Map<Integer, Integer> get = remote.getBulk();
assertEquals(100, get.size());
for(int i = 0; i < 100; i++) {
assertTrue(get.containsValue(i));
assertTrue(get.containsKey(i));
}
}
{code}
Also attaching test file for this functionality.
--
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, 7 months
[JBoss JIRA] (ISPN-3436) Not working RemoteManager.getBulk() and keySet() in compatibility mode
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3436?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-3436:
------------------------------
Description:
When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
{code:borderStyle=solid}
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
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)
...
{code}
Code that did it:
{code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
public void testEmbeddedPutHotRodGetBulk() {
Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
populateCacheManager(embedded);
Map<Integer, Integer> get = remote.getBulk();
assertEquals(100, get.size());
for(int i = 0; i < 100; i++) {
assertTrue(get.containsValue(i));
assertTrue(get.containsKey(i));
}
}
{code}
was:
When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
{code:borderStyle=solid}
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
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)
...
{code}
Code that did it:
{code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
public void testEmbeddedPutHotRodGetBulk() {
Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
populateCacheManager(embedded);
Map<Integer, Integer> get = remote.getBulk();
assertEquals(100, get.size());
for(int i = 0; i < 100; i++) {
assertTrue(get.containsValue(i));
assertTrue(get.containsKey(i));
}
}
{code}
Also attaching test file for this functionality.
> Not working RemoteManager.getBulk() and keySet() in compatibility mode
> ----------------------------------------------------------------------
>
> Key: ISPN-3436
> URL: https://issues.jboss.org/browse/ISPN-3436
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Reporter: Jiří Holuša
> Assignee: Galder Zamarreño
>
> When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST).
> {code:borderStyle=solid}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B
> 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)
> ...
> {code}
> Code that did it:
> {code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid}
> public void testEmbeddedPutHotRodGetBulk() {
> Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache();
> RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache();
> populateCacheManager(embedded);
> Map<Integer, Integer> get = remote.getBulk();
> assertEquals(100, get.size());
> for(int i = 0; i < 100; i++) {
> assertTrue(get.containsValue(i));
> assertTrue(get.containsKey(i));
> }
> }
> {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, 7 months
[JBoss JIRA] (ISPN-3435) Enable tests for RemoteCache.getBulk() and keySet()
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3435:
---------------------------------
Summary: Enable tests for RemoteCache.getBulk() and keySet()
Key: ISPN-3435
URL: https://issues.jboss.org/browse/ISPN-3435
Project: Infinispan
Issue Type: Enhancement
Components: Remote protocols
Reporter: Jiří Holuša
Assignee: Galder Zamarreño
When exploring tests for HotRod client and operations getBulk() and keySet() found out that in org.infinispan.client.hotrod.BulkGetKeys*Test the inherited test methods from BaseBulkGetKeys*Test aren't running due to absent @Test annotation.
Also in pull request added tests for getBulk() even for REPL 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, 7 months
[JBoss JIRA] (ISPN-3175) Upgrade the java hotrod client to support remote querying
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3175?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3175:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2022
> Upgrade the java hotrod client to support remote querying
> ---------------------------------------------------------
>
> Key: ISPN-3175
> URL: https://issues.jboss.org/browse/ISPN-3175
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Labels: jdg62
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> Once we'll have ISPN-3169(define query fluent API), ISPN-3173(add a new query operation over hotrod) and ISPN-3174(String-based query language) in place, this is about connecting the dots: invoke the remote query on the server and present the result to the user.
> h3.On the client side
> As described in ISPN-3173, the query is sent as a byte[] to the server: the payload.
> The request payload is query specific (not defined in the HR protocol) and at this stage has the following format: [Q_TYPE] [QUERY_ST] [FIRST_INDEX] [PAGE_SIZE]. This format accommodates the remote query requirements as defined in ISPN-3169.
> - Q_TYPE (protobuf's byte) and query identifier, 1 for JPAQL (this is the query type we'll support). In future we'll add different query types as well.
> - QUERY_STRING (protobuf's string)- JPAQL string generated by the fluent API (ISPN-3169). Parameters are encoded in this string (vs being sent separately)
> - FIRST_INDEX + PAGE_SIZE (protobuf's int)- used for paginating/iterating over the result set.
> HR response: [HR_SUCESS_FLAG] [payload]
> PAYLOAD = [NUM_EL] [PROJ_SIZE] [ELEMENTS]
> - even though at this stage we don't support projections (see ISPN-3169) PROJ_SIZE is added for future compatibility when projection will be supported.
> Note that the payload for both request and response should be marshalled with protobuf as this information is read/written over multiple clients.
> h3.On the server side
> - the server module reads the query operation and the payload (byte[])
> - invokes QueryFacade.query(byte[]) : byte[]
> - QueryFacade is an interface defined in the server modules
> - has an implementation in the remote-query module (new modules)
> - the reason for adding this module: RemoteQueryImpl cannot be in the server modules (ASL) as it has a dependency on the query module (LGPL) which would "contaminate" the server module. Another option would be to merge it in the query module itself, but doesn't feel like a natural fit as its responsibility is serializing data (protobuf). OTOH if it is small we can merge it there so that we don't add a new module to the system?
>
> For an overview on the remote querying see https://community.jboss.org/wiki/QueryingDesignInInfinispan
--
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, 7 months
[JBoss JIRA] (ISPN-1965) Some entries not available during view change
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-1965:
-------------------------------------
Mircea, I thought NBST was implemented so that the data is available during the view change. Can you please shed some light on the part of the design which alows for data not to be available during view change and thus, why this issue was rejected? Thanks
> Some entries not available during view change
> ---------------------------------------------
>
> Key: ISPN-1965
> URL: https://issues.jboss.org/browse/ISPN-1965
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.3.FINAL
> Reporter: Michal Linhard
> Assignee: Dan Berindei
>
> In the 4 node, dist mode, num-owners=2, elasticity test
> http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
> there is a cca 90 sec period of time where clients get null responses to GET
> requests on entries that should exist in the cache.
> first occurence:
> hyperion1139.log 05:31:01,202 286.409
> last occurence:
> hyperion1135.log 05:32:45,441 390.648
> total occurence count: (in all 19 driver nodes)
> 152241
> (this doesn't mean it happens for 152K keys, because each key is retried after
> erroneous attempt)
> data doesn't seem to be lost, because these errors cease after a while and
> number of entries returns back to normal (see cache_entries.csv)
> this happens approximately in the period between node0001 is killed and cluster
> {node0002 - node0004} is formed (and shortly after).
--
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, 7 months