[ https://jira.jboss.org/jira/browse/ISPN-317?page=com.atlassian.jira.plugi... ] Mircea Markus reassigned ISPN-317: ---------------------------------- Assignee: Mircea Markus (was: Manik Surtani) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno reassigned ISPN-317: ------------------------------------- Assignee: Galder Zamarreno (was: Mircea Markus) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno edited comment on ISPN-317 at 7/12/10 10:05 AM: ----------------------------------------------------------------- Apart from when unsafeReturnValues is false, you also need to check do this when unsafeUnreliableReturnValues is true, we are in a TX and the command is conditional. Also, I wonder whether you'll need to maintain two ops as well when conditional operations are in used in general. The reason is that DI tries to apply the change locally first, so if a particular node might not have the latest values in memory. So, if you didn't do the remote get, putIfAbsent calls could succeed assuming a particular node was not in memory but another member in the cluster had it. By doing the remote get first, it would have found the value and would not have allowed the op. Similar thing happens with a conditional replace based on previous value. If the previous value is not present locally, without the remote get it would not be brought and hence you wouldn't be able to guarantee that the operation will work as expected. was (Author: galder.zamarreno(a)jboss.com): Apart from when unsafeReturnValues is false, you also need to check do this when unsafeUnreliableReturnValues is true, we are in a TX and the command is conditional. Also, I wonder you'll need to maintain two ops as well when conditional operations are in used in general. The reason is that DI tries to apply the change locally first, so if a particular node might not have the latest values in memory. So, if you didn't do the remote get, putIfAbsent calls could succeed assuming a particular node was not in memory but another member in the cluster had it. By doing the remote get first, it would have found the value and would not have allowed the op. Similar thing happens with a conditional replace based on previous value. If the previous value is not present locally, without the remote get it would not be brought and hence you wouldn't be able to guarantee that the operation will work as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno commented on ISPN-317: --------------------------------------- I had a closer look into this and I'm not sure doing it for CR2 would be a good thing since it seems to me that it'd require a bit of refactoring. First of all, optimising into one operation could only be done when unsafeReturnValues is false and the command is not conditional. Currently DistributionInterceptor sends a ClusteredGetCommand per each key to lookup. Multiple keys could be affected for example if PutMap was called. So, any single call will have to be a MultipleRpcCommand that contains all the CGCs commands plus the write command. Now, the problem here is that MultipleRpcCommand.perform simply executes the commands and always returns null. So the return of those clustered gets would be lost. It would require some kind of refactoring involving returning a List<List<Response>> where for each node, we get a list of responses for each of the ops executed locally. However, RpcManagerImpl seems to assume List<Response> all around, so, it looks to me this change would require a fair bit of refactoring and I don't think we should be doing it for 4.1.0.CR2. Mircea, if you had a different idea, let me know. For the moment I'm reassigning it to you and setting fix version to 5.1.0.Beta1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno updated ISPN-317: ---------------------------------- Fix Version/s: 5.1.0.BETA1 (was: 4.1.0.CR2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.sys... ] Galder Zamarreno reassigned ISPN-317: ------------------------------------- Assignee: Galder Zamarreno (was: Mircea Markus) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-317: ---------------------------------- Fix Version/s: 5.1.0.BETA2 (was: 5.1.0.BETA1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-317: ---------------------------------- Fix Version/s: 5.1.0.BETA4 (was: 5.1.0.BETA3) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-317: ---------------------------------- Fix Version/s: 5.1.0.CR1 (was: 5.1.0.BETA5) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Manik Surtani commented on ISPN-317: ------------------------------------ Is ISPN-1539 a duplicate of this issue? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-317: ---------------------------------- Fix Version/s: 5.1.0.CR2 (was: 5.1.0.CR1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-317: ------------------------------- Fix Version/s: 5.2.0.FINAL (was: 5.1.0.CR3) Affects Version/s: 5.1.0.FINAL Complexity: Medium -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-317: ------------------------------- Fix Version/s: 6.0.0.Final (was: 5.2.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