[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1090: ----------------------------------- Description: This JIRA will act as a place to keep track of enhancements to the Hot Rod protocol that should be included in version 2 of the protocol: - We need a new error status code so that clients can detect when a node has been suspected and so react accordingly (i.e. not bubble it up but instead failover). Currently, this can be solved by checking whether the error message contains SuspectException but this is not nice. - Since we're not gonna be supporting asymmetric clusters in the mean time, we need a new error status code to deal with situations where the cache is not defined in the server. Currently we check for CacheNotFoundException in the message but that's not nice. was: This JIRA will act as a place to keep track of enhancements to the Hot Rod protocol that should be included in version 2 of the protocol: - We need a new error status code so that clients can detect when a node has been suspected and so react accordingly (i.e. not bubble it up but instead failover). Currently, this can be solved by checking whether the error message contains SuspectException but this is not nice. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1090: ---------------------------------------- Well, for an L1 in clients you need listeners so that you can be notified when things change on the server side. I think this is important, particularly cos a lot of people using Coherence like the L1 capabilities that they bring. Anyway, the L1 and event listeners is already covered in a separate JIRA. This jira is more geared towards having: - Small improvements that do not need a separate jira - Link to bigger jiras such as ISPN-484 or ISPN-374. The custom commands could be interesting but I'd like to see concrete use cases for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Manik Surtani edited comment on ISPN-1090 at 5/9/11 11:44 AM: -------------------------------------------------------------- Good idea for an umbrella JIRA. Could you make sure the others are linked accordingly? These would include: * Eventing over Hot Rod * Transactions over Hot Rod * Map/Reduce over Hot Rod * Querying over Hot Rod We have JIRAs for at least some of the above. :) was (Author: manik): Good idea for an umbrella JIRA. Could you make sure the others are linked accordingly? These would include: * Eventing over Hot Rod * Transactions over Hot Rod * Map/Reduce over Hot Rod -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1090: ---------------------------------------- Manik, I've linked those now. If you see more, just link them :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-1090 at 5/15/11 11:37 AM: ------------------------------------------------------------------ Another interesting idea: - It'd be interesting for error messages to have 0-n parameters sent back to the client. This way, you could formalize suspect exceptions being thrown back to the client in such way that servers could tell clients in a more explicit way which node was suspected and so they could avoid trying to failover to that node if their topology view has not been updated. At the moment there's no formalization of this, so to implement this would require clients parsing the error message in a particular way to derive this information, and relying on this is too brittle. Note: In the case of SuspectException, to make this more reliable, it would require that an API change is done so that it includes a member instance variable. This is probably something worth doing now, just before 5.0 release. I'll create a separate jira for this. was (Author: galder.zamarreno): Another interesting idea: - It'd be interesting for error messages to have 0-n parameters sent back to the client. This way, you could formalize suspect exceptions being thrown back to the client in such way that servers could tell clients in a more explicit way which node was suspected and so they could avoid trying to failover to that node if their topology view has not been updated. At the moment there's no formalization of this, so to implement this would require clients parsing the error message in a particular way to derive this information, and relying on this is too brittle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1090: ---------------------------------------- Well, once you get a SuspectException, if you want to retrieve the address you'd do getAddress(), so it's an addition to the API to be specific. This would also need a new constructor to take the message + address. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1090: -------------------------------- Fix Version/s: 5.2.0.Final (was: 5.1.0.BETA1) (was: 5.1.0.Final) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-1090 at 7/7/11 8:31 AM: ---------------------------------------------------------------- To support virtual nodes more efficiently, the hash topology header must change: - -When virtual nodes are enabled, we're sending host:port information repeated for each of the hash ids belonging to a HotRod server. So, the protocol needs to be more efficient in v2 sending the host:port only once and then N hash ids, where N is the number of configured virtual nodes. If virtual nodes is disabled, the default is 1 virtual node, so N=1.- Actually, forget what I just said cos as Manik rightly pointed out in a chat we had earlier, it won't be atypical to configure with 500-1000 vnodes. So, even if we applied the suggested change, that'd still require, for a cluster of 10 nodes, shipping 10*1000*4bytes=~40kb which is not very optimal. During the chat it was suggested that the clients themselves generate the hash ids, but in order to do that, they need to have the same hash seed that the Infinispan server does, and currently that is org.infinispan.remoting.transport.Address which represents the cluster address. Clearly, this won't work for clients but what about if the server hashed on String UTF-8 version of org.infinispan.remoting.transport.Address? If that worked, then a hash topology update need only shipping: existing header params plus num virtual nodes, and tuples for host:port:clusterAddress(UTF-8). The key thing here is that the number of tuples to send back would be equal to the number of nodes in the cluster. The clients could then generate the hash codes for all virtual nodes themselves. At the moment, Infinispan cluster addresses are backed by JGroups address which are UUID driven, so its toString() representation seems deterministic. However, if there was ever a move back to IP based addresses that would break because toString() representations rely on DNS lookups which means the toString() representation could vary over time. @Pete, could you confirm whether this change on the key on which cluster addresses are hashed would work as expected? The hash topology header size could be further reduced if clients were assumed to be able to keep state in which case the server could just send information about nodes that have joined or left. Since nodes pick fixed positions in the hash wheel, this would in theory work cos the addition of a node would not require other nodes to recalculate hashes. was (Author: galder.zamarreno): To support virtual nodes more efficiently, the hash topology header must change: - When virtual nodes are enabled, we're sending host:port information repeated for each of the hash ids belonging to a HotRod server. So, the protocol needs to be more efficient in v2 sending the host:port only once and then N hash ids, where N is the number of configured virtual nodes. If virtual nodes is disabled, the default is 1 virtual node, so N=1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1090?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-1090: ------------------------------------ The only problem I see is that there are a lot of places in the test suite where we rely on the address of the server mapping to that server as the first owner. So it would require some changes in the test suite. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira