June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3150) Allow specifying "Accept" type for REST server for byte array values

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3150?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3150: ----------------------------------- Fix Version/s: 5.3.0.CR2 > Allow specifying "Accept" type for REST server for byte array values > -------------------------------------------------------------------- > > Key: ISPN-3150 > URL: https://issues.jboss.org/browse/ISPN-3150 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.3.0.CR2, 5.3.0.Final > > > Currently, byte array values are sent to the client with Content-type:application/x-java-serialized-object > See https://github.com/infinispan/infinispan/blob/master/server/rest/src/main... > It would be nice if the default value for byte arrays was application/octet-stream because serializable types are already being sent back as application/x-java-serialized-object, which covers the case when a custom object (not byte array) is put in the cache. Or allow users to specify octet-stream by "Accept" HTTP header. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3150) Allow specifying "Accept" type for REST server for byte array values

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3150?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3150: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow specifying "Accept" type for REST server for byte array values > -------------------------------------------------------------------- > > Key: ISPN-3150 > URL: https://issues.jboss.org/browse/ISPN-3150 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.3.0.Final > > > Currently, byte array values are sent to the client with Content-type:application/x-java-serialized-object > See https://github.com/infinispan/infinispan/blob/master/server/rest/src/main... > It would be nice if the default value for byte arrays was application/octet-stream because serializable types are already being sent back as application/x-java-serialized-object, which covers the case when a custom object (not byte array) is put in the cache. Or allow users to specify octet-stream by "Accept" HTTP header. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3164) Replacing entry via Memcached does not increment version of original HotRod entry

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3164?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3164: ---------------------------------------- Martin, this is similar to ISPN-3163. That's now fixed in master, which results in all server endpoints using the same mechanism to up the version whenever there's a modification. Can you verify if this issue is still present? > Replacing entry via Memcached does not increment version of original HotRod entry > --------------------------------------------------------------------------------- > > Key: ISPN-3164 > URL: https://issues.jboss.org/browse/ISPN-3164 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > When an entry is stored via HotRod and later replaced by Memcached (or Embedded, it does not matter), the version of the entry does not change. This makes operations like replaceWithVersion of HotRod client unreliable in compatibility mode. > {code:java} > public void testHotRodPutMemcachedReplaceHotRodGetVersionedTest() throws Exception { > final String key1 = "6"; > // 1. Put with Hot Rod > RemoteCache<String, Object> remote = cacheFactory.getHotRodCache(); > assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key1, "v1")); > VersionedValue oldValue = remote.getVersioned(key1); > // 2. Replace with Memcached > Future<Boolean> f = cacheFactory.getMemcachedClient().set(key1, 0, "v2"); > assertTrue(f.get(60, TimeUnit.SECONDS)); > // 3. Get with HotRod > assertEquals("v2", remote.getVersioned(key1).getValue()); > assertTrue("The entry version should have changed", oldValue.getVersion() != remote.getVersioned(key1).getVersion()); > //^^^ fails here > } > {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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3211) Upgrade to Hibernate Search 4.3.0.Final

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3211?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3211: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1889 > Upgrade to Hibernate Search 4.3.0.Final > --------------------------------------- > > Key: ISPN-3211 > URL: https://issues.jboss.org/browse/ISPN-3211 > Project: Infinispan > Issue Type: Component Upgrade > Components: Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 5.3.0.CR2, 5.3.0.Final > > -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3211) Upgrade to Hibernate Search 4.3.0.Final

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3211: ------------------------------------- Summary: Upgrade to Hibernate Search 4.3.0.Final Key: ISPN-3211 URL: https://issues.jboss.org/browse/ISPN-3211 Project: Infinispan Issue Type: Component Upgrade Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.3.0.CR2, 5.3.0.Final -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3210) JPA Cache Store expects 5.2 in namespace, it should be 5.3

by Ray Tsang (JIRA)

Ray Tsang created ISPN-3210: ------------------------------- Summary: JPA Cache Store expects 5.2 in namespace, it should be 5.3 Key: ISPN-3210 URL: https://issues.jboss.org/browse/ISPN-3210 Project: Infinispan Issue Type: Feature Request Reporter: Ray Tsang Assignee: Mircea Markus -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3196) ReplicatedConsistentHashFactory does not spread ownership evenly

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3196?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3196: -------------------------------- Fix Version/s: 5.3.0.Final > ReplicatedConsistentHashFactory does not spread ownership evenly > ---------------------------------------------------------------- > > Key: ISPN-3196 > URL: https://issues.jboss.org/browse/ISPN-3196 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Critical > Fix For: 5.3.0.CR2, 5.3.0.Final > > > When primary ownership between nodes should be balanced in ReplicatedConsistentHashFactory, the transferOwnership method in fact always moves ALL segments' ownership to the new node. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3140: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.3.0.CR2 Resolution: Done Integrated in master. Thanks! > JMX operation to suppress state transfer > ---------------------------------------- > > Key: ISPN-3140 > URL: https://issues.jboss.org/browse/ISPN-3140 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, State transfer > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 5.3.0.CR2, 5.3.0.Final > > > This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default. > The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be: > 1) Shut down application requests to the data grid > 2) Suppress state transfer on all nodes via JMX > 3) Bring down all nodes > 4) Perform maintenance work > 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX. > 6) Once all nodes are up, enable state transfer for each node again via JMX > 7) Allow application requests to reach the grid again. > The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down). > This is a small but useful subset of full manual state transfer as defined in ISPN-1394. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3209) Server operation to suppress state transfer

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3209?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3209: ------------------------------------- Assignee: Tristan Tarrant (was: Mircea Markus) > Server operation to suppress state transfer > ------------------------------------------- > > Key: ISPN-3209 > URL: https://issues.jboss.org/browse/ISPN-3209 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache, State transfer > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > > This issue is to provide a Server operation for the functionality implemented in ISPN-3140 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3209) Server operation to suppress state transfer

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3209?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3209: ---------------------------------- Component/s: Server (was: Distributed Cache) (was: State transfer) > Server operation to suppress state transfer > ------------------------------------------- > > Key: ISPN-3209 > URL: https://issues.jboss.org/browse/ISPN-3209 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > > This issue is to provide a Server operation for the functionality implemented in ISPN-3140 -- 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, 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 June 2013