May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3050) Cache.replace should support arrays of primitive types

by Adam Kovari (JIRA)

[ https://issues.jboss.org/browse/ISPN-3050?page=com.atlassian.jira.plugin.... ] Adam Kovari commented on ISPN-3050: ----------------------------------- Thanks Galder, Mircea. > Cache.replace should support arrays of primitive types > ------------------------------------------------------ > > Key: ISPN-3050 > URL: https://issues.jboss.org/browse/ISPN-3050 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.1.Final > Environment: - JBoss EAP 6.1.0 Alpha > - Infinispan 5.2.1.Final > Reporter: Adam Kovari > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > org.infinispan.Cache.replace does not handle values as arrays of primitive types well. It compares the old and new value as .equals but this doesn't work for arrays of primitives. It should use Arrays.equals for such a case. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2281) Enable inter server endpoint communication in a compatibility mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2281?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2281: ----------------------------------- Fix Version/s: (was: 5.3.0.Beta1) > Enable inter server endpoint communication in a compatibility mode > ------------------------------------------------------------------ > > Key: ISPN-2281 > URL: https://issues.jboss.org/browse/ISPN-2281 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode. > Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator. > When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well). > For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above. > May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?). > In-VM may need registration of an Externalizer? -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3050) Cache.replace should support arrays of primitive types

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3050?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3050: ----------------------------------- Fix Version/s: 5.3.0.Beta2 > Cache.replace should support arrays of primitive types > ------------------------------------------------------ > > Key: ISPN-3050 > URL: https://issues.jboss.org/browse/ISPN-3050 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.1.Final > Environment: - JBoss EAP 6.1.0 Alpha > - Infinispan 5.2.1.Final > Reporter: Adam Kovari > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > org.infinispan.Cache.replace does not handle values as arrays of primitive types well. It compares the old and new value as .equals but this doesn't work for arrays of primitives. It should use Arrays.equals for such a case. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3050) Cache.replace should support arrays of primitive types

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3050?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-3050. ------------------------------------ Resolution: Done > Cache.replace should support arrays of primitive types > ------------------------------------------------------ > > Key: ISPN-3050 > URL: https://issues.jboss.org/browse/ISPN-3050 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.1.Final > Environment: - JBoss EAP 6.1.0 Alpha > - Infinispan 5.2.1.Final > Reporter: Adam Kovari > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.3.0.Final, 5.3.0.Beta2 > > > org.infinispan.Cache.replace does not handle values as arrays of primitive types well. It compares the old and new value as .equals but this doesn't work for arrays of primitives. It should use Arrays.equals for such a case. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3050) Cache.replace should support arrays of primitive types

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3050?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3050: ---------------------------------------- Documentation on the topic: https://docs.jboss.org/author/x/2oD2Aw > Cache.replace should support arrays of primitive types > ------------------------------------------------------ > > Key: ISPN-3050 > URL: https://issues.jboss.org/browse/ISPN-3050 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.1.Final > Environment: - JBoss EAP 6.1.0 Alpha > - Infinispan 5.2.1.Final > Reporter: Adam Kovari > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > org.infinispan.Cache.replace does not handle values as arrays of primitive types well. It compares the old and new value as .equals but this doesn't work for arrays of primitives. It should use Arrays.equals for such a case. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3050) Cache.replace should support arrays of primitive types

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3050?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3050: ---------------------------------------- Adam, this is already possible since it was made possible thanks to ISPN-2281: https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... > Cache.replace should support arrays of primitive types > ------------------------------------------------------ > > Key: ISPN-3050 > URL: https://issues.jboss.org/browse/ISPN-3050 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.1.Final > Environment: - JBoss EAP 6.1.0 Alpha > - Infinispan 5.2.1.Final > Reporter: Adam Kovari > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 5.3.0.Final > > > org.infinispan.Cache.replace does not handle values as arrays of primitive types well. It compares the old and new value as .equals but this doesn't work for arrays of primitives. It should use Arrays.equals for such a case. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2891) Gap in time between commit of transaction and actual value update

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2891: ---------------------------------------- Re: IRC chat {code}[22:21] <jcrossley3> galderz: in case you're still around [22:22] <jcrossley3> new ConfigurationBuilder().build() defaults useSynchronization to true [22:22] <jcrossley3> if that's a bug, i can file a jira{code} [~jcrossley], that's not a bug, that's just the default configuration (as in, what Infinispan provides as default configuration, nothing to do with what AS defines as default configuration) which is correct. If you're trying to apply some extra configuration on what's on the XML, you need to read that configuration and then call new ConfigurationBuilder.read(Configuration), passing in the base configuration you've read from XML, or whichever way the AS provides that configuration... > Gap in time between commit of transaction and actual value update > ----------------------------------------------------------------- > > Key: ISPN-2891 > URL: https://issues.jboss.org/browse/ISPN-2891 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.1.Final > Reporter: Jim Crossley > Assignee: Mircea Markus > Labels: 5.2.x > Fix For: 5.3.0.CR1, 5.3.0.Final > > Attachments: bad.log, good.log, pessimistic.log, ugly.log > > > Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on. > The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic. > We've confirmed the failure on 5.2.2 as well. > Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531... > So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test. > It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3. > These tests always pass locally. They only ever fail on CI, which runs *very* slowly. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2973) HotRod client doesn't retry on suspect

by Takayoshi Kimura (JIRA)

[ https://issues.jboss.org/browse/ISPN-2973?page=com.atlassian.jira.plugin.... ] Takayoshi Kimura commented on ISPN-2973: ---------------------------------------- I don't have it and I'm asking original reporter if he has it. > HotRod client doesn't retry on suspect > -------------------------------------- > > Key: ISPN-2973 > URL: https://issues.jboss.org/browse/ISPN-2973 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.2.2.Final > Reporter: Takayoshi Kimura > Assignee: Tristan Tarrant > Fix For: 5.2.6.Final, 5.3.0.CR1, 5.3.0.Final > > > HotRod client does retry on RemoteNodeSuspectException and Codec10#checkForErrorsInResponseStatus() checks message from server if it contains "Suspect" message. > ISPN-2737 fix changed the message and HotRod is unable to perform retry as there is no "Suspect" string in the message from server. > ISPN-2737 PullReq: https://github.com/infinispan/infinispan/pull/1629 and commit https://github.com/galderz/infinispan/commit/3ee1b96ace284ba108eb3abfd855... -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3143) Cannot store custom objects via HotRod and read via REST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3143?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3143: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Final) > Cannot store custom objects via HotRod and read via REST > -------------------------------------------------------- > > Key: ISPN-3143 > URL: https://issues.jboss.org/browse/ISPN-3143 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR1 > > > The following test fails when added to EmbeddedRestHotRodTest > {code:java} > public void testCustomObjectHotRodPutEmbeddedRestGet() throws Exception{ > final String key = "4"; > Person p = new Person("Martin"); > // 1. Put with Hot Rod > RemoteCache<String, Object> remote = cacheFactory.getHotRodCache(); > assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key, p)); > // 2. Get with Embedded > assertTrue(cacheFactory.getEmbeddedCache().get(key) instanceof Person); > assertEquals(p.getName(), ((Person) cacheFactory.getEmbeddedCache().get(key)).getName()); > // 3. Get with REST > HttpMethod get = new GetMethod(cacheFactory.getRestUrl() + "/" + key); > cacheFactory.getRestClient().executeMethod(get); > assertEquals(HttpServletResponse.SC_OK, get.getStatusCode()); > //^^^ fails here - status code 500, status text: NullPointerException > Object returnedPerson = remote.getRemoteCacheManager().getMarshaller().objectFromByteBuffer(get.getResponseBodyAsString().getBytes()); > assertTrue(returnedPerson instanceof Person); > assertEquals(p.getName(), ((Person) returnedPerson).getName()); > } > public static class Person implements Serializable { > private String name; > public Person(String name) { > this.name = name; > } > public String getName() { > return name; > } > } > {code} > Storing and retrieving String keys works correctly. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3143) Cannot store custom objects via HotRod and read via REST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3143?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3143: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done integrated, thanks > Cannot store custom objects via HotRod and read via REST > -------------------------------------------------------- > > Key: ISPN-3143 > URL: https://issues.jboss.org/browse/ISPN-3143 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > The following test fails when added to EmbeddedRestHotRodTest > {code:java} > public void testCustomObjectHotRodPutEmbeddedRestGet() throws Exception{ > final String key = "4"; > Person p = new Person("Martin"); > // 1. Put with Hot Rod > RemoteCache<String, Object> remote = cacheFactory.getHotRodCache(); > assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key, p)); > // 2. Get with Embedded > assertTrue(cacheFactory.getEmbeddedCache().get(key) instanceof Person); > assertEquals(p.getName(), ((Person) cacheFactory.getEmbeddedCache().get(key)).getName()); > // 3. Get with REST > HttpMethod get = new GetMethod(cacheFactory.getRestUrl() + "/" + key); > cacheFactory.getRestClient().executeMethod(get); > assertEquals(HttpServletResponse.SC_OK, get.getStatusCode()); > //^^^ fails here - status code 500, status text: NullPointerException > Object returnedPerson = remote.getRemoteCacheManager().getMarshaller().objectFromByteBuffer(get.getResponseBodyAsString().getBytes()); > assertTrue(returnedPerson instanceof Person); > assertEquals(p.getName(), ((Person) returnedPerson).getName()); > } > public static class Person implements Serializable { > private String name; > public Person(String name) { > this.name = name; > } > public String getName() { > return name; > } > } > {code} > Storing and retrieving String keys works correctly. -- 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, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013