[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3140:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1887
> 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.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
[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3140:
------------------------------------
Pasted from Adrian's message ([http://markmail.org/message/ns7aojy7v7su2t7p]):
{quote}
1. Add a JMX writable attribute (or operation?) to ClusterTopologyManager (name it suppressRehashing?) that is false by default but should also be configurable via API or xml. While this attribute is true the ClusterTopologyManager queues all join/leave/exclude(see below) requests and does not execute them on the spot as it would normally happen. [...] When it is set back to false all queued operations (except the ones that cancel eachother out) are executed. The setter should be synchronous so when setting is back to false it does not return until the queue is empty and all rehashing was processed.
2. We add a JMX operation excludeNodes(list of addresses) to ClusterTopologyManager. [...] This operation removes the node from the topology (almost as if it left) and forces a rebalance. The node is still present in the current CH but not in the pending CH. It's basically disowned by all its data which is now being transferred to other (not excluded) nodes. At the end of the rebalance the node is removed from topology for good and can be shut down without loosing data. Note that if suppressRehashing==false operation excludeNodes(..) just queues them for later removal. We can batch multiple such exclusions and then re-activate the rehashing.
The parts that need to be implemented are written in italic above. Everything else is already there.
excludeNodes is a way of achieving a soft shutdown and should be used only if we care about preserving data int the extreme case where the nodes are the last/single owners. We can just kill the node directly if we do not care about its data.
suppressRehashing is a way of achieving some kind of batching of topology changes. This should speed up state transfer a lot because it avoids a lot of pointless reshuffling of data segments when we have many successive joiners/leavers.
So what happens if the current coordinator dies for whatever reason? The new one will take control and will not have knowledge of the existing rehash queue or the previous status of suppressRehashing attribute so it will just get the current cache membership status from all members of current view and proceed with the rehashing as usual. If the user does not want this he can set a default value of true for suppressRehashing. The admin has to interact now via JMX with the new coordinator. But that's not as bad as the alternative where all the nodes are involved in this jmx scheme :) I think having only the coordinator involved in this is a plus.
{quote}
We're actually going to implement only point 1 now, and point 2 will be a separate issue (or perhaps as a part of ISPN-1394).
> 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.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
[JBoss JIRA] (ISPN-3206) REST endpoint returns Expiry header in default locale for the server
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3206?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3206:
-------------------------------------
All existing tests are passing on my localhost with this fix (even those dependent on Locale).
> 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
>
>
> 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
[JBoss JIRA] (ISPN-3206) REST endpoint returns Expiry header in default locale for the server
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3206?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3206:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1886
> 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
>
>
> 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
[JBoss JIRA] (ISPN-3190) Memcached server throwing NullPointerException if the mashaller is not explicitly set
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3190?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3190:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1885
> Memcached server throwing NullPointerException if the mashaller is not explicitly set
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3190
> URL: https://issues.jboss.org/browse/ISPN-3190
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.3.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> According to the tutorial at https://docs.jboss.org/author/display/ISPN/Interoperability+between+Embed... it is not necessary to specify a special marshaller under normal circumstances. However, the Memcached server seems to require it in any case and the Memcached client's "get" operation fails because we did not set any marshaller for the compatibility mode and it remained null. Note that I'm not using SpyMemcached.
> My understanding is that even if I use SpyMemcached to retrieve the entry, it will be found and retrieved but without the marshaller I simply won't understand the returned value. But something will be returned. Is my assumption correct?
> {code}
> 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.container.EntryFactoryImpl] Retrieved from container ImmortalCacheEntry{key=4, value=MetadataImmortalCacheValue {value=v1, metadata=EmbeddedMetadata{lifespan=-1, maxIdle=-1, version=ServerEntryVersion(1)}}}
> 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.interceptors.CallInterceptor] Executing command: GetKeyValueCommand {key=4, flags=[OPERATION_MEMCACHED]}.
> 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.commands.read.GetKeyValueCommand] Found entry ImmortalCacheEntry{key=4, value=MetadataImmortalCacheValue {value=v1, metadata=EmbeddedMetadata{lifespan=-1, maxIdle=-1, version=ServerEntryVersion(1)}}}
> 2013-06-05 14:12:19,055 ERROR (MemcachedServerWorker-6) [org.infinispan.interceptors.InvocationContextInterceptor] ISPN000136: Execution error
> java.lang.NullPointerException
> at org.infinispan.server.memcached.MemcachedTypeConverter.marshall(MemcachedTypeConverter.scala:58)
> at org.infinispan.server.memcached.MemcachedTypeConverter.unboxValue(MemcachedTypeConverter.scala:45)
> at org.infinispan.server.memcached.MemcachedTypeConverter.unboxValue(MemcachedTypeConverter.scala:37)
> at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitGetKeyValueCommand(TypeConverterInterceptor.java:93)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:96)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:399)
> at org.infinispan.DecoratedCache.getCacheEntry(DecoratedCache.java:514)
> at org.infinispan.server.memcached.MemcachedDecoder.get(MemcachedDecoder.scala:122)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:121)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:75)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:385)
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
> 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}
--
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
[JBoss JIRA] (ISPN-3206) REST endpoint returns Expiry header in default locale for the server
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3206?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-3206:
--------------------------------
Description:
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.
was:
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.
We should ensure that the Expiry header is returned in US locale as well and not to be server specific.
> 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
>
>
> 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
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Michael Musgrove updated ISPN-375:
----------------------------------
Fix Version/s: 6.0.0.Alpha3
(was: 5.3.0.Final)
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote protocols
> Reporter: Galder Zamarreño
> Assignee: Michael Musgrove
> Priority: Blocker
> Labels: hackathon
> Fix For: 6.0.0.Alpha3
>
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
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
[JBoss JIRA] (ISPN-3206) REST endpoint returns Expiry header in default locale for the server
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3206:
-----------------------------------
Summary: 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
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.
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