Commit Graph

10 Commits

Author SHA1 Message Date
Mihaela Stoica
6dcc00d017 CA-205204: Uncaught exception during RPU
When an exception is reported during the RPU, XenCenter tries to re-enable the host. But when this fails, we should just ignore it and report the original exception.

Signed-off-by: Mihaela Stoica <Mihaela.Stoica@citrix.com>
2016-03-24 17:18:53 +00:00
Mihaela Stoica
6d40a6db2b CA-204191: Trying to avoid Uncaught exception System.InvalidOperationException: Object is currently in use elsewhere.
Signed-off-by: Mihaela Stoica <Mihaela.Stoica@citrix.com>
2016-03-17 16:12:43 +00:00
Mihaela Stoica
8d0c6e64ff CA-156200: HANDLE_INVALID shown on Rolling Pool Upgrade completed page
- while upgrading a host, throw a HOST_OFFLINE ("Server could not be contacted") exception if the host can no longer be resolved (instead of HANDLE_INVALID)
- also corrected the parameters of the HANDLE_INVALID exception, as an extra parameter is needed for the friendly error name.
- in the UpdateManualHostPlanAction class I replaced Host with the private property _host in several places, so we are no longer trying to resolve the host each time we want to write something into logs
- added some null checks, to avoid reporting null reference exception

Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
2015-04-17 14:56:40 +01:00
Gabor Apati-Nagy
aefed11165 Revert "CA-149867: Invoke on MainWindow instead of various controls"
This reverts commit 92f0499911.
2015-04-16 14:17:02 +01:00
Gabor Apati-Nagy
92f0499911 CA-149867: Invoke on MainWindow instead of various controls
We observed that some threads can reach deadlock-ish state after they have Invoked into a control's UI thread. When it happens they are all in a waiting for join or in sleep state for very long time, although there should not be any deadlock situations.
It seems this has something to do with multiple parent controls and with which control we invoked on. This should not make a difference, because we have got one UI thread (for MainWindow) they should wait for, but we have seen it does.

The solution that fixed this issue was to invoke on the MainWindow instead of various controls (see a4fe507adf ).

This changeset is changing all our Invokes to invoke into MainWindow
instead of a control itself. (MainWindow's UI thread is the only UI thread
all Control is using in XenCenter)
This changeset should be in place until we have found the root cause or the exact reason for the above.
2015-04-08 15:16:10 +01:00
Mihaela Stoica
a4fe507adf CA-147941: Fixed the RPU wizard hang in "Reconnecting Storage" and connecting action stuck in progress state
In some cases calling Control.Invoke() from a background thread causes that thread to go in a "sleep, wait, or join" mode, while waiting for Invoke to happen, although the UI thread is running normally.
If the Control is the MainWindow, it works as expected, but we've seen it happening while connecting or disconnecting from a large pool, on calling Invoke on controls like NavigationView, AlertSummaryPage, HistoryPage, etc.
To fix this, we call the Invoke on the MainWindow in all the places where we've seen the issue.

With this changes, the previous fix for CA-148245 (call RequestRefreshTreeView on CacheClearing event) is not needed anymore, so I removed that call.

Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
2014-10-10 13:16:50 +01:00
Konstantina Chremmou
d1c0da5d54 PlanAction simplification: removed PlanActionStatusChangedEventArgs class; use Action<T>
delegate; renamed event and its event hadler.

Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
2013-12-21 12:52:28 +00:00
Konstantina Chremmou
a128847717 AutomaticBackgroundThread and SemiAutomaticBackgroundThread simplification: moved
common code to the base class BackgroundThreadBase; removed classes inheriting from
EventArgs; use Action/Action<T> delegates instead of EventHandler<T>.

Signed-off-by: Konstantina Chremmou <konstantina.chremmou@citrix.com>
2013-12-21 11:36:20 +00:00
Mihaela Stoica
15c02aa2c9 CA-90855: Allow Rolling Pool Upgrade wizard to be resumed when master has
been previously upgraded.

Introduced Host.LongProductVersion property which returns host's
product version and build number (e.g. 5.6.100.72258), or null if
product version can't be found. We use this property to check
if the master has been updraded and to decide which slaves need
to be upgraded or to skip hosts already upgraded.

Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
2013-06-28 15:50:14 +01:00
Mihaela Stoica
bd36a85bff CP-4816: Initial commit to git repo
Signed-off-by: Mihaela Stoica <mihaela.stoica@citrix.com>
2013-06-24 12:41:48 +01:00