Failing site login blocks multisite application

We just updated to MIPSDK 23.1 and are facing a problem we have not seen before.

If we try to login to a site that is offline it fails as expected.

However, when we login to another working site after that, the call to ImageViewerControlWpf.Connect not only connects to the camera on the second site but also attempts a new login to the first offline site. This is done on the UI thread (since ImageViewerControlWpf.Connect cannot be run async) with a fairly long timeout.

Is there a way this can be avoided? We only want to call ImageViewerControlWpf.Connect with minimal risk of getting stuck at a timeout since it will block the UI thread.

Best regards

Ola Nygren

A solution could be to set masteronly to true when logging in. This way the ImageViewerControl will only communicate with the server you are logging into.

Is it enough to set masterOnly=true on Environment.Login only or do I need it for Environment.AddServer as well? Are there any side-effects when setting this flag?

I have now tried to set masterOnly=true on both Environment.Login and Environment.AddServer with no effect. Any ImageViewerWpfControl.Connect is still blocked after a failed Environment.Login. Any other ideas?

Hmm, that sounds weird. MasterOnly is made to stop the configuration to grab data from other servers.

Just to be clear. You have two servers connected in a MFA setup and when you log into server1 while server2 is down, you see problems in ImageViewerWpfControl? If both servers are running you don’t see any problems?

My suggestion should make it possible to login to server1 while server2 is down, but the limitiation would be that if both servers are up, you will not be able to get data from server2 without logging into the server directly.

To be specific, if you log into server1 while server2 is down (with masteronly set to true), you still see the problem?

We are doing a component integration with a lot of sites, 30+. I guess MFA is the same thing but with plugin integration?

As long as we only connect to online sites the system works as expected. The problem starts when we stumble upon a site which we cannot connect to.

After this, MIPSDK will always retry a login to this site, on the UI thread, even when we access other online sites.

I can step into MIPSDK when the application freezes and see it gets stuck at:

- ConfigurationAsync.EnsureAllConfigurationLoaded

- ParallellHandler.PopulateUserContext

This problem is releated to another forum post I posted the other week, https://developer.milestonesys.com/s/question/0D53X0000C1VC3pSQG/nullreference-when-lifting-privacy-mask.

Before the update to MIPSDK 2022 R3 we did not have to call Environment.Login and therefore we did not get any data in UserContext.LoginSettings.

I guess that is why we did not see this problem before. Now we have to run Environment.Login for the exports to work and that is why LoginSettings is populated and we get stuck at login attempt to the offline site.

Does it make sence? :slight_smile:

Best regards,

Ola

Is there maybe a way to delete the offline site from the LoginSettings list or maybe check that the site accessible before trying to login? I think that should solve the problem.

/Ola

I checked with one of my colleagues who suggested to lower the timeout:

https://doc.milestonesys.xyz/developer/html/index.html?base=miphelp/class_video_o_s_1_1_platform_1_1_environment_options.html&tree=tree_search.html?search=connectionchecktimeout

You could test with 1 second. The downside to this is, if you set it too low and bad networkconnection, you might not be able to establish a connection.

I’ll look into cleaning up LoginSettings, the only weird thing is, that with MasterOnly set to true. LoginSettings should only contain one server

I don’t think settings a low timeout is an option since a lot of sites are quite remote and need a long timeout to connect. I small fix where offline servers are not reconnected unless asked to, would be much appreciated. :slight_smile:

By the way, it looks like I can get this problem even when I don’t run the Environment.Login method.

/Ola

I added a ping-check on the XProtect server before attempting to connect to it. This way I think I will be able to filter out most of the problematic systems. There is still the possibility to end up with the scenario described above but it is less likely.

Best regards,

Ola

I will setup a sample to reproduce your issue.

I’m a bit confused about what you mean by connecting to sites. Could you explain the flow, like:

  • Find url to site
  • Environment.AddServer
  • Environment.Login
  • Find Camera FQID
  • ImageViewerControl Set Camera FQID
  • ImageViewerControl Connect

I would expect the above would be all you need if you connect to one server. If you have multipe servers connected in an MFA (all servers knows each other), you would log into he main server and have access to the Camera FQID of all the servers.

If you have multiple servers not connected in an MFA we are looking at another scenario which we don’t usually have and would have to look into a solution for.

By “connecting to a site” I mean getting a server Item that is used primary to connect cameras in the ImageViewerWpfControl.

Connecting to a site is done with the following steps:

1. Add credentials to a CredentialsCache

2. Environment.AddServer

3. Environment.Login

4. Environment.LoadSiteItem

Opening a camera in ImageViewerWpfControl is done with the following steps.

1. Connect to site if it is not already connected.

2. Get Item for camera with Configuration.Instance.GetItem

3. Create ImageViewerWpfControl

4. ImageViewerWpfControl.CameraFQID = Item.FQID

5. ImageViewerWpfControl.Initialize()

6. ImageViewerWpfControl.Connect()

The different servers dont know about each other, so I guess it is not a MFA integration.

Best regards,

Ola

Then we are in a different scenario, we expected you where in an MFA setup and that is what the timeout and MasterOnly could help with.

You don’t write anything about logout, do you ever logout from a server? Unless you need to have quick access to multiple cameras on multiple systems, I would suggest that you logout when you connect to a new site. This would solve the issue since loging out will remove the server from the list and the connect will not try to reconnect all servers which have been connected.

I currently dont do any logout. Since login takes a few seconds I rather have the sites connected unless there are big drawbacks with that. I have been thinking of maybe disconnect sites that have not been used for a long time.

From what you are saying, maybe a solution to my problem could be to call logout in my login error handling code. That way this site will not be considered when connecting a camera.

However, since ImageViewerWpfControl.Connect must be run on the UI thread I really think you should try to minimize the work this method does. Retrying login to servers that is not involved with the specific camera feels like a thing that can be avoided.

I will take your suggestion up with the team and see if we can add it to our backlog

Thank you for your help and cooperation.

Have a nice day!

Your issue has been picked up as a bug. It won’t make it into this release, but we expect to get it into the next one.

I wanted to ensure I could reproduce this, when I tried to follow your steps having two servers running. Connecting to both (with different credentials) and connecting to a camera. Then I shutdown the server I’m not connected to and choose another camera. But I don’t get the delay. Can you supply my with sample code which gives the issue?

I did a minimal sample that I thought would give the problem but it did not. I am attaching the code so that you can get an idea of what I am doing. It is hard to see what is causing the problem in my main application. I dont initialize any playbackcontroller in my minimal sample and I view much more cameras in my main application. There are probably other differences that I can’t think of right now.

What I can see it that UI thread waits at Login in ServerInfo.Polulate with server info pointing to the failing server. This is done even when connecting to a camera at any other, working server. Attaching a screenshot so you can see exactly where in code I am refering to.

Its even harder for me to replicate it as I don’t have the same setup as you do. Would it be possible take your main application and strip down to figure what component is causing this? It sounds like its some combination of imageviewer and something else. This would also explain why I’m not seeing it in my test application.