June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3205) Upgrade to JGroups 3.3.1.Final

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3205?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3205: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to JGroups 3.3.1.Final > ------------------------------ > > Key: ISPN-3205 > URL: https://issues.jboss.org/browse/ISPN-3205 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > 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-3191) TopologyAwareDistributedCacheTest failing randomly

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-3191?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-3191: -------------------------------- Assignee: Anna Manukyan (was: Galder Zamarreño) > TopologyAwareDistributedCacheTest failing randomly > -------------------------------------------------- > > Key: ISPN-3191 > URL: https://issues.jboss.org/browse/ISPN-3191 > Project: Infinispan > Issue Type: Bug > Components: Querying > Reporter: Galder Zamarreño > Assignee: Anna Manukyan > Labels: testsuite_stability > Fix For: 5.3.0.Final > > > Failing with: https://gist.github.com/galderz/b384a05f8b94d56873e2 -- 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-3213) Upgrade to JCache 0.7

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-3213: -------------------------------------- Summary: Upgrade to JCache 0.7 Key: ISPN-3213 URL: https://issues.jboss.org/browse/ISPN-3213 Project: Infinispan Issue Type: Component Upgrade Components: JCache Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.3.0.CR2, 5.3.0.Final Upgrade to JCache 0.7 (https://groups.google.com/forum/#!topic/jsr107/vYRLv2xsveA) and see if issues WRT annotation integration highlighted in ISPN-2855 are fixed. -- 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-3212) Modularization

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3212: ------------------------------------- Summary: Modularization Key: ISPN-3212 URL: https://issues.jboss.org/browse/ISPN-3212 Project: Infinispan Issue Type: Task Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 6.0.0.Final This task is about restructuring Infinispan to make it more modular, including reducing compulsory dependencies -- 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-3205) Upgrade to JGroups 3.3.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3205?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reopened ISPN-3205: ----------------------------------- > Upgrade to JGroups 3.3.1.Final > ------------------------------ > > Key: ISPN-3205 > URL: https://issues.jboss.org/browse/ISPN-3205 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > 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-3205) Upgrade to JGroups 3.3.1.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3205?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3205: ---------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/1884, https://github.com/infinispan/infinispan-server/pull/115 (was: https://github.com/infinispan/infinispan/pull/1884) > Upgrade to JGroups 3.3.1.Final > ------------------------------ > > Key: ISPN-3205 > URL: https://issues.jboss.org/browse/ISPN-3205 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > 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-3164) Replacing entry via Memcached does not increment version of original HotRod entry

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3164?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-3164: ------------------------------------- Yes, the above test passes now. So this issue was fixed in ISPN-3163 > 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-3206) REST endpoint returns Expiry header in default locale for the server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3206?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3206: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.3.0.Final Resolution: Done > REST endpoint returns Expiry header in default locale for the server > -------------------------------------------------------------------- > > Key: ISPN-3206 > URL: https://issues.jboss.org/browse/ISPN-3206 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.3.0.CR2, 5.3.0.Final > > > Rest endpoint uses RESTEasy to generate responses and uses .expires(date) method of the respective response builder. However, the currently used RESTEasy version (org.jboss.resteasy:resteasy-jaxrs:jar:2.3.2.Final) uses the server's default locale (in my case it was cs_CZ) which caused the Expiry header to have the following format: Čt, 06 VI 2013 19:24:02 CEST (also see RESTEASY-887). OTOH, the 2.3.2 version of RESTEasy generates Last-Modified always in US locale. > It is also causing some tests to fail on different locales than US, e.g.: > {code} > testHotRodEmbeddedPutRestGetExpiry(org.infinispan.it.compatibility.EmbeddedRestHotRodTest) Time elapsed: 0.023 sec <<< FAILURE! > java.text.ParseException: Unparseable date: "?t, 06 VI 2013 16:32:04 CEST" > at java.text.DateFormat.parse(DateFormat.java:357) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.assertDate(EmbeddedRestHotRodTest.java:291) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.testHotRodEmbeddedPutRestGetExpiry(EmbeddedRestHotRodTest.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > We should ensure that the Expiry header is returned in US locale as well and not to be server specific. -- 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-3206) REST endpoint returns Expiry header in default locale for the server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3206?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3206: ----------------------------------- Affects Version/s: 5.2.6.Final > REST endpoint returns Expiry header in default locale for the server > -------------------------------------------------------------------- > > Key: ISPN-3206 > URL: https://issues.jboss.org/browse/ISPN-3206 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.6.Final, 5.3.0.CR1 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.3.0.CR2, 5.3.0.Final > > > Rest endpoint uses RESTEasy to generate responses and uses .expires(date) method of the respective response builder. However, the currently used RESTEasy version (org.jboss.resteasy:resteasy-jaxrs:jar:2.3.2.Final) uses the server's default locale (in my case it was cs_CZ) which caused the Expiry header to have the following format: Čt, 06 VI 2013 19:24:02 CEST (also see RESTEASY-887). OTOH, the 2.3.2 version of RESTEasy generates Last-Modified always in US locale. > It is also causing some tests to fail on different locales than US, e.g.: > {code} > testHotRodEmbeddedPutRestGetExpiry(org.infinispan.it.compatibility.EmbeddedRestHotRodTest) Time elapsed: 0.023 sec <<< FAILURE! > java.text.ParseException: Unparseable date: "?t, 06 VI 2013 16:32:04 CEST" > at java.text.DateFormat.parse(DateFormat.java:357) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.assertDate(EmbeddedRestHotRodTest.java:291) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.testHotRodEmbeddedPutRestGetExpiry(EmbeddedRestHotRodTest.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:722) > {code} > We should ensure that the Expiry header is returned in US locale as well and not to be server specific. -- 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: ----------------------------------- Affects Version/s: 5.3.0.CR1 5.2.6.Final > 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 > Affects Versions: 5.2.6.Final, 5.3.0.CR1 > 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013