-
1. Re: client/server setup - remote data GET manipulation
nadirx Feb 2, 2015 6:34 AM (in response to naskoos)1 of 1 people found this helpfulIn REST mode, the server you connect to will be responsible for retrieving the entry from the primary owner and returning to you (which might involve one RPC if the server is not the owner).
In HotRod, the client is "intelligent" in that it is aware of both the topology of the server cluster and of the hashing of the entries, so that it will directly contact the primary owner.
-
2. Re: client/server setup - remote data GET manipulation
rvansa Feb 2, 2015 6:37 AM (in response to naskoos)The client communicates only with the server where it sent the request; the actual data owner could be unknown to the client. So the owner will send the response to the contacted server and this returns it to the client.
With HotRod, in most cases the client will know which server owns the data, and therefore it will contact it directly. ('in most cases', because during failure handling the clients contacts random servers and after cluster membership the client may have outdated topology information).
-
3. Re: client/server setup - remote data GET manipulation
nadirx Feb 2, 2015 6:42 AM (in response to nadirx)1 of 1 people found this helpfulI will add two open unassigned issues on a Jira related to implementing topology awareness in REST:
[ISPN-5185] Optionally add topology information to REST headers - JBoss Issue Tracker
[ISPN-5186] Implement a topology-aware RESTful client - JBoss Issue Tracker
Contributions are welcome
-
4. Re: client/server setup - remote data GET manipulation
naskoos Feb 2, 2015 7:28 AM (in response to naskoos)Thank you all for your quick answers.
I'm prototyping an elasticity mechanism for NoSQL DBs running on the cloud and I'm preparing a use case based on infinispan for the next paper. This paper is used a as base one.
As I'm examining vertical scaling (adding/removing VMs), maybe I could incorporate to my prototype a mechanism to inform HotRod for changes in the topology. If you are interested this elasticity mechanism could be incorporated to the HotRod adding a cloud elasticity feature (when it's ready)!
-
5. Re: client/server setup - remote data GET manipulation
rvansa Feb 2, 2015 10:48 AM (in response to naskoos)Not sure if I understand, but HotRod already gets the topology info with first request to the cluster with changed topology.
-
6. Re: client/server setup - remote data GET manipulation
naskoos Feb 2, 2015 10:59 AM (in response to rvansa)I see... Informing HotRod about the topology change is not important as it's done with minimum overhead.
However, adding to the HotRod the ability to change dynamically the number of used nodes/servers (# of occupied VMs in the cloud) it might be interesting as it would have both economic and performance benefits to the user!
-
7. Re: client/server setup - remote data GET manipulation
rvansa Feb 2, 2015 11:54 AM (in response to naskoos)I still don't see what you want to achieve. HotRod is started with list of servers it should try to connect to, and then it uses any servers that are available - clustered together. The server instances cannot be controlled through HotRod.
-
8. Re: client/server setup - remote data GET manipulation
naskoos Feb 2, 2015 12:28 PM (in response to rvansa)I'm just saying: What if they could be controlled through HotRod!
Would you be interested in such a feature or it is something out of scope for the HotRod server?
-
9. Re: client/server setup - remote data GET manipulation
rvansa Feb 3, 2015 3:33 AM (in response to naskoos)I think that this is really out of scope. The aim of HotRod is to read/write data server, in future to execute remote code on the data etc., but not management operations. For management, there is JMX interface, you can connect to the servers with CLI etc. For servers elasticity, see JBoss AS/Wildfly Domain Mode feature.
-
10. Re: client/server setup - remote data GET manipulation
naskoos Feb 3, 2015 9:55 AM (in response to rvansa)ok!
Thank you Radim for your time!