[ http://jira.jboss.com/jira/browse/JGRP-619?page=all ] Vladimir Blagojevic updated JGRP-619: ------------------------------------- Description: Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead to convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer. We have to simplify this process! State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. This issue is closely related to revamping of channel state transfer callbacks - JGRP-563 was: Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer. We have to simplify this process! State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. This issue is closely related to revamping of channel state transfer callbacks - JGRP-563 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-619?page=com.atlassian.jira.plugin.s... ] Bela Ban commented on JGRP-619: ------------------------------- Replace uses of ChannelNotConnectedException and ChannelClosedException with their superclass ChannelException. This way, we don't have to add new exceptions to methods getState(), connect() (and send()) when we create subclasses of StateTransferException (for example), or add other subclasses of ChannelException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-619?page=com.atlassian.jira.plugin.s... ] Bela Ban commented on JGRP-619: ------------------------------- To prevent the following code: public byte[] getState() { try { return Util.objectToByteBuffer(stocks.clone()); } catch(Exception ex) { ex.printStackTrace(); return null; } } , which returns null on a serialization exception, and thus doesn't reach the caller of JChannel.getState(), we'd have to add an exception to the state callbacks ... The above code could thus be shortened to: public byte[] getState() throws Exception { return Util.objectToByteBuffer(stocks.clone()); } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-619?page=com.atlassian.jira.plugin.s... ] Bela Ban commented on JGRP-619: ------------------------------- Leaving the timeout in for now. Users might want to have a second line of defense to bound a state transfer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira