[JBoss JIRA] (ISPN-3772) Reduce marshalling payload sizes
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3772?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3772:
-----------------------------------
Description:
Apply some marshalling improvements:
1. Marshall instances of java.util.Arrays$ArrayList with ArrayListExternalizer so that it occupies less space.
2. RegularEnumSet and JumboEnumSet should be detected and they should be written using SetExternalizer. For an enum set with a single value, this means going from writing 41 bytes to 10 bytes.
3. Avoid sending OPERATION_X flags when compatibility mode is disabled.
4. Current array support in JBoss Marshalling ends up writing class information even for know types. Try to figure out a way to detect the most commonly written arrays in Infinispan and find an efficient way to marshall them.
was:
Apply some marshalling improvements:
1. Marshall instances of java.util.Arrays$ArrayList with ArrayListExternalizer
so that it occupies less space.
2. RegularEnumSet and JumboEnumSet should be detected and they should be written using SetExternalizer. For an enum set with a single value, this means going from writing 41 bytes to 10 bytes.
3. Avoid sending OPERATION_X flags when compatibility mode is disabled.
4. Current array support in JBoss Marshalling ends up writing class information even for know types. Try to figure out a way to detect the most commonly written arrays in Infinispan and find an efficient way to marshall them.
> Reduce marshalling payload sizes
> --------------------------------
>
> Key: ISPN-3772
> URL: https://issues.jboss.org/browse/ISPN-3772
> Project: Infinispan
> Issue Type: Enhancement
> Components: Marshalling
> Affects Versions: 6.0.0.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 6.1.0.Final
>
>
> Apply some marshalling improvements:
> 1. Marshall instances of java.util.Arrays$ArrayList with ArrayListExternalizer so that it occupies less space.
> 2. RegularEnumSet and JumboEnumSet should be detected and they should be written using SetExternalizer. For an enum set with a single value, this means going from writing 41 bytes to 10 bytes.
> 3. Avoid sending OPERATION_X flags when compatibility mode is disabled.
> 4. Current array support in JBoss Marshalling ends up writing class information even for know types. Try to figure out a way to detect the most commonly written arrays in Infinispan and find an efficient way to marshall them.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3772) Reduce marshalling payload sizes
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-3772:
--------------------------------------
Summary: Reduce marshalling payload sizes
Key: ISPN-3772
URL: https://issues.jboss.org/browse/ISPN-3772
Project: Infinispan
Issue Type: Enhancement
Components: Marshalling
Affects Versions: 6.0.0.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 6.1.0.Final
Apply some marshalling improvements:
1. Marshall instances of java.util.Arrays$ArrayList with ArrayListExternalizer
so that it occupies less space.
2. RegularEnumSet and JumboEnumSet should be detected and they should be written using SetExternalizer. For an enum set with a single value, this means going from writing 41 bytes to 10 bytes.
3. Avoid sending OPERATION_X flags when compatibility mode is disabled.
4. Current array support in JBoss Marshalling ends up writing class information even for know types. Try to figure out a way to detect the most commonly written arrays in Infinispan and find an efficient way to marshall them.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3771) HotRod SSL is not working properly with IBM JDKs -- SSLHandshakeException
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-3771:
----------------------------------
Summary: HotRod SSL is not working properly with IBM JDKs -- SSLHandshakeException
Key: ISPN-3771
URL: https://issues.jboss.org/browse/ISPN-3771
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 6.0.0.Final
Environment: Both RHEL x64 and x32 architecture using IBM JDK 6 or IBM JDK 7.
Test is passing for Open-jdk and Oracle-jdk.
Reporter: Tomas Sykora
Assignee: Mircea Markus
Attachments: hotRodSSLibmJDKsProblem
For reproducing, run mvn clean verify -Psuite.examples -DfailIfNoTests=false -Dtest=ExampleConfigsTest#testSSLHotRodConfig in Infinispan-server testsuite, using IBM JDK 7.
See attached file for stack trace.
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by V L (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
V L edited comment on ISPN-3766 at 11/28/13 6:20 AM:
-----------------------------------------------------
Hi William. Thanks for your response.
{quote}That is because it also pays attention to write skews. In your case you are trying to later modify your value in the same transaction, but another transaction has changed the value, which is a write skew (PFER has it's own transaction).{quote}
I think I got your logic on write skews, but now I'm not sure I fully understand the logic of PFER as described here http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_putforextern...
PFER purpose is to store values from data source for other readers, to improve performance. My sample shows that I can use it only for store data that can't be changed during current transaction ?
was (Author: exmortal):
Hi William. Thanks for your response.
{quote}That is because it also pays attention to write skews. In your case you are trying to later modify your value in the same transaction, but another transaction has changed the value, which is a write skew (PFER has it's own transaction).{quote}
I think I got your logic on write skews, but now I'm not sure I fully understand the logic of PFER that described here http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_putforextern...
PFER purpose is to store values from data source for other readers, to improve performance. My sample shows that I can use it only for store data that can't be changed during current transaction ?
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Assignee: Mircea Markus
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> Thanks
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3770) Incorrect Content-Type header when putting object via REST and get with different Accept
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3770?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-3770:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan-server/pull/198
> Incorrect Content-Type header when putting object via REST and get with different Accept
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3770
> URL: https://issues.jboss.org/browse/ISPN-3770
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
>
> When putting serialized object via REST post and then getting it back with different Accept header (for example application/json), the retrieved data has still the "creation-time" Content-Type and data doesn't change in any way.
> I would expect retrieving nice json structure for instace.
> Code snippet:
> {code}
> public void testCustomObjectGetAcceptJSONAndXML() throws Exception{
> String fullPathKeyA = fullPathKey(KEY_A);
> TestSerializable object = new TestSerializable("CONTENT");
> ByteArrayOutputStream bout = new ByteArrayOutputStream();
> ObjectOutputStream oo = new ObjectOutputStream(bout);
> oo.writeObject(object);
> oo.flush();
> oo.close();
> byte[] byteData = bout.toByteArray();
> post(fullPathKeyA, byteData, "application/x-java-serialized-object");
> HttpResponse getJson = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/json");
> assertTrue(getJson.getHeaders("Content-type")[0].getValue().contains("application/json")); //this assertion fails
> HttpResponse getXml = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/xml");
> assertTrue(getXml.getHeaders("Content-type")[0].getValue().contains("application/xml")); //this assertion fails
> }
> {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
10 years, 5 months
[JBoss JIRA] (ISPN-3770) Incorrect Content-Type header when putting object via REST and get with different Accept
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-3770:
---------------------------------
Summary: Incorrect Content-Type header when putting object via REST and get with different Accept
Key: ISPN-3770
URL: https://issues.jboss.org/browse/ISPN-3770
Project: Infinispan
Issue Type: Bug
Components: Server
Reporter: Jiří Holuša
Assignee: Mircea Markus
When putting serialized object via REST post and then getting it back with different Accept header (for example application/json), the retrieved data has still the "creation-time" Content-Type and data doesn't change in any way.
I would expect retrieving nice json structure for instace.
Code snippet:
{code}
public void testCustomObjectGetAcceptJSONAndXML() throws Exception{
String fullPathKeyA = fullPathKey(KEY_A);
TestSerializable object = new TestSerializable("CONTENT");
ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutputStream oo = new ObjectOutputStream(bout);
oo.writeObject(object);
oo.flush();
oo.close();
byte[] byteData = bout.toByteArray();
post(fullPathKeyA, byteData, "application/x-java-serialized-object");
HttpResponse getJson = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/json");
assertTrue(getJson.getHeaders("Content-type")[0].getValue().contains("application/json")); //this assertion fails
HttpResponse getXml = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/xml");
assertTrue(getXml.getHeaders("Content-type")[0].getValue().contains("application/xml")); //this assertion fails
}
{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
10 years, 5 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by V L (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
V L edited comment on ISPN-3766 at 11/28/13 5:36 AM:
-----------------------------------------------------
Hi William. Thanks for your response.
{quote}That is because it also pays attention to write skews. In your case you are trying to later modify your value in the same transaction, but another transaction has changed the value, which is a write skew (PFER has it's own transaction).{quote}
I think I got your logic on write skews, but now I'm not sure I fully understand the logic of PFER that described here http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_putforextern...
PFER purpose is to store values from data source for other readers, to improve performance. My sample shows that I can use it only for store data that can't be changed during current transaction ?
was (Author: exmortal):
Hi William. Thanks for your response.
{quote}That is because it also pays attention to write skews. In your case you are trying to later modify your value in the same transaction, but another transaction has changed the value, which is a write skew (PFER has it's own transaction).{quote}
I think I got your logic on write skews, but now I'm fully understand the logic of PFER that described here http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_putforextern...
PFER purpose is to store values from data source for other readers, to improve performance. My sample shows that I can use it only for store data that can't be changed during current transaction ?
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Assignee: Mircea Markus
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> Thanks
--
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
10 years, 5 months
[JBoss JIRA] (ISPN-3670) Any commands received before the initial topology is installed should block
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3670?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3670:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Any commands received before the initial topology is installed should block
> ---------------------------------------------------------------------------
>
> Key: ISPN-3670
> URL: https://issues.jboss.org/browse/ISPN-3670
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 6.1.0.Final
>
>
> Because the initial cache topology is installed in a single phase, it's possible to receive a StateRequestCommand from another node before receiving the JOIN response from the coordinator and installing the initial cache topology. As such, commands received before we have a cache topology should block instead of being ignored.
> This bug is especially visible in the Map/Reduce tests (e.g. ReplicatedTwoNodesMapReduceTest) because the M/R task sends the CreateCacheCommand to the other nodes before it's executed on the originator. Since the originator happens to be the coordinator, it's possible for the coordinator to start the rebalance before the first member installed the initial topology.
--
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
10 years, 5 months