[infinispan-issues] [JBoss JIRA] Commented: (ISPN-448) Consider all topology cache updates to be done by coordinator in Hot Rod

[Galder Zamarreño (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608857#comment-12608857 ] 

Galder Zamarreño commented on ISPN-448:
---------------------------------------

As a result of ISPN-1182, I've done some initial investigation of this and it's a bit more complicated than originally thought. The obvious way to implement this is by having a @ViewChanged method and within it update the topology view. However, whereas removing topology addresses is simple, adding new addresses here is difficult because the ViewChangeEvent does not carry server host and port settings.

Even if a node adds a [Address:Server Host+Port] k/v mapping to the topology cache on startup, this might happen after the view change has been sent around. So, for the coordinator to deal with this properly, two steps would be needed:
- To deal with new nodes joining, have a cache listener that listeners for puts on topology cache with an Address instance. The coordinator would then be able to fetch this address host+port and would be able to construct the TopologyAddress and update the view.
- To deal with joins leaving or crashing, have a @ViewChanged method, similar to the one that the code has at the moment to deal with crashed members.

One downside of this solution is that each node joining would lead to a topology view update cluster wide, whereas if it had been resolvable in the @ViewChanged method, we could potentially deal with multiple joins in just one go.

What would be cool would be if ViewChangeEvent could carry arbitrary information provided by the user. Why that? Because when the JGroups channel is started, the host+port are known, and so it'd be cool if the user could provide information to carry along with this node's JGroups or Infinispan address when this is constructed. This information would be exchanged at GMS time and so any view change event would then carry this extra info.


> Consider all topology cache updates to be done by coordinator in Hot Rod
> ------------------------------------------------------------------------
>
>                 Key: ISPN-448
>                 URL: https://issues.jboss.org/browse/ISPN-448
>             Project: Infinispan
>          Issue Type: Task
>          Components: Cache Server
>            Reporter: Galder Zamarreño
>            Assignee: Galder Zamarreño
>             Fix For: 6.0.0.Final
>
>
> Based on the discussion below, consider all topology cache updates to be done by coordinator to avoid concurrency issues when updating it.
> > Looks  good.
> > What is causing this unsuccessful add? If it is caused by timeouts due
> > to multiple caches operating on the same key an alternative would be
> > to only perform the operation on the coordinator and rest of the
> > members to have node added listeners ... 
> Currently, each node when it starts, it's responsible of adding itself to the view and when it stops, it's responsible from removing itself. Apart from this, there's a crashed member listener running only in coordinator that detects whether any member left without updating the topology view. Your suggestion to have the coordinator control it all seems like could work and get around potential timeouts. 
> I'll create a JIRA to investigate this but won't do it for CR1 since I'm expect this to be a major issue. Metadata size is small and it's not constantly uddated.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira