]
Bela Ban commented on JGRP-2362:
--------------------------------
OK, I changed the logic for handling view changes slightly: the coord now removes all data
({{remove_all_data_on_view_change == true}}) or only coord data
({{remove_all_data_on_view_change == true}}) regardless of whether the coordinator
changed, or not.
The second small change is that {{writeAll()}} only fetches data of non-removed members.
This change will be in master pending a successful testsuite run. Try it out and let me
know whether this works for you.
Providing logical member name in JDBC_PING
------------------------------------------
Key: JGRP-2362
URL:
https://issues.jboss.org/browse/JGRP-2362
Project: JGroups
Issue Type: Feature Request
Affects Versions: 4.0.17, 4.0.18, 4.0.19, 4.1.0, 4.0.20
Reporter: S Pokutniy
Assignee: Bela Ban
Priority: Minor
Fix For: 4.1.3
When using JDBC_PING and logical names instead of UUIDs and one of the cluster member
crashes or get killed and this member is not coordinator then its database set still
remains in the database as long as coordinator changes (independently from
remove_old_coords_on_view_change /remove_all_data_on_view_change). If the the cluster is
then restarted the old dataset makes connect() much slower (+30 seconds), as the members
seem to be tryting to connect to it. Parameter remove_all_data_on_view_change seems to be
the solution but it does not work as long as coordinator does not change, so practically
the same as remove_old_coords_on_view_change.
The only solution seems to be to provide an appropriate delete statement in parameter
initialize_sql, which would delete old entry, for example like this: delete from
JGROUPSPING where ping_data like '%logical name%'. However, this is neither really
quick nor the ideal solution, as ping_data's datatype is bytea or bit varying.
It would be great to have also logical name in JGROUPSPING, which is instead per default
in insert(). This is also easy to implement as there is access to this information in
PingData.