richard-austin/cloud-server

Cloud service for one or more security-cam NVR systems

cloud-server's Issues

Thread pool too small, multi pages of multi live streams hit the limit

On the login form the focus should be on the username field on opening

This probably applies to other forms too, on Security Cam and Cloud

Session timeout is active on multi video view

The session is automatically logged out after 10 minutes. I haven't noticed if the session timeout countdown dialogue box is shown in the last minute.

Session timeout active when not logged in

The session timeout is meaningless with no authenticated session.

Logout from one Cloud session can cause streams on another session to stall

I thought I had fixed this by making stealMessage only steal the message if the token was correct (otherwise sending the message on to respondToBrowser and trying the next message). This has indeed improved things hugely, but I have seen a stream drop out once since this change was added.

If there were two or more clients logging in or out simultaneously there would be two messages to steal. It looks like the best way to handle this is to make a map of tokens against buffers and splitMessages checks each message token against the map and assigns the buffer to that token in the map if matching, then signals stealMessage.

This is likely to be due to stolenBuffer being updated again in splitMessages before stealMessage has passed it on to its destination.

Refresh of multi cam page can sometimes have one or more video views not picking up the stream

Heartbeat pings do not detect connection down when exception thrown in acceptConnectionsFromCloudProxy

In Cloud.java with throwEx set as below (firing every 5 executions), the 15 byte Ignore message appears to heve been sent correcly from the CloudProxy even though restart was called in the catch block.

private void acceptConnectionsFromCloudProxy(final int cloudProxyFacingPort) {
acceptConnectionsFromCloudProxyExecutor.execute(() -> {
while (running) {
try {
// Creating a ServerSocket to listen for connections with
ServerSocketChannel s = ServerSocketChannel.open();
s.bind(new InetSocketAddress(cloudProxyFacingPort));
while (running) {
try {
// It will wait for a connection on the local port
SocketChannel cloudProxy = s.accept();
cloudProxy.configureBlocking(true);
throwEx();
remainsOfPreviousBuffer = null;
this.cloudProxy = cloudProxy;
clearSocketMap();
startCloudProxyInputProcess();
}
catch (Exception ex) {
logger.severe("Exception in acceptConnectionsFromCloudProxy: " + ex.getClass().getName() + ": " + ex.getMessage());
Thread.sleep(5000);
restart();
}
}
} catch (Exception ioex) {
logger.severe("Exception in acceptConnectionsFromCloudProxy: " + ioex.getClass().getName() + ": " + ioex.getMessage());
restart();
}
}
});
}

The periodic getTemperature call usually causes the stomp ws connection to be re-made.

This happens occasionally with the browser directly connected to the NVR.

Look at network connections on the browser while a video is running.

With ActiveMQ version: Video stream can continue if browser terminates

It appears that the video traffic between the NVR and loud can sometimes continue if a browser hosting a video id terminated uncleanly.

CloudProxy does not reconnect to Cloud after Cloud restarts.

This is when the server restarts after a rebuild in development. Possibly the CloudProxy remains connected to the old socket which becomes orphaned but not closed?

Sometimes each camera can get listed more than once on the Select camera menu

I think this may be due to the _loggedIn flag in utilsService being false when the application is actually logged in, but can't see how that might happen.

CameraService.initialiseCameras is not clearing the cameraStreams and cameras arrays before pushing to them so assumes they are starting empty. Any situation where initialiseCameras is called after those arrays are already set up will cause this issue.

This occurred after logging in with, I believe, the correct credentials, getting no login error message but remaining logged out, then logging in again successfully.

Refreshing the browser restores normal operation.

Some API calls return HTML on error when NVR not connected

Establish a session with a connected NVR and browser.
Disconnect the NVR.
Try get wifi details, there will be HTML returned on the API call which shows in the error message notification.

Tried on 03/07/2022, and nothing was returned, no HTML and nothing else

05/07/2022
Error response set up for when Cloud is closed, but during the time between NVR disconnecting and the Cloud instance timing out, HTML can be returned on API calls on a production build (error status 502). 502 (bad gateway) would be from nginx and the HTML will be its own error response, so I need to override that.

Error status: 502

<title>502 Bad Gateway</title>

502 Bad Gateway

---

nginx

When ActiveMQ service is unavailable, Cloud web application hangs during start.

Not possible to connect a browser to the Cloud Service in this case.

• It should be possible to connect a browser, but with a warning that ActiveMQ is not reachable (perhaps only viewable with admin login).
• Admin should be able to set the ActiveMQ url.

CloudProxy does not reconnect to Cloud after Cloud restarts.

Menu names are listed inline instead of in a column in narrow mode (as on phone)

In admin mode, the getUserAuthorities calls switch the display back to the home page

If the users table is shown, the display reverts to nav bar only on the first getUserAuthorities AJAX call.

Browser often needs <CTRL> F5 when first connecting to the host via Cloud/CloudProxy

Very often API calls will return an error until the browser (Chrome) has been hard refreshed.

This is generally after just starting Linux and and the Cloud/CloudProxy. Stopping those processes and closing the browser then restarting them does not reproduce the error so it seems to need to have been down a while for this to happen (to do with caching?). It didn't happen after restarting Linux and starting again, it seems to need a longer shutdown for this to happen.

Auto restart on saving changes causes multiple thread instances and goes to 100% CPU

In dev mode, the cloudwebapp needs to be shut down before saving changes to prevent this. See if that requirement can be avoided.

See if recycling can be handled better in sendRequestToCloudProxy

This is complicated by interaction with stealMessage and that it is called in a number of places. It may not need to be a submitted thread.