Tobias.vonLienen Posted January 18 Share Posted January 18 We are having the problem that results in our inventory queries are not always updating properly. For example, I have created a query that shows "FileWave Client Version" running on a specific client. Let's take Client -1133 as example: The query shows that the installed FWClient version is 14.10.2, but when I open the Client Info it says that version 15.2.1 is installed. (different last connected times are because of the time between the screenshots) It's also now been almost a week since 15.2.1 has been installed. We have this problem in some other instances, for example when we want to find out what version of a program or app is installed on a client, and the query shows and older version even though we are sure that we have installed a newer version more than 24h ago. Is there a way to force a client to update its inventory? Link to comment Share on other sites More sharing options...
Moderators Sean Posted January 18 Moderators Share Posted January 18 Do the client logs show if inventory back to the server was successful? Link to comment Share on other sites More sharing options...
Tobias.vonLienen Posted January 19 Author Share Posted January 19 this client -1133 incidentally updated its query now since I've posted. I have another client -1317 where the log says "Data successfully sent to the inventory server" but the first time it was successful was only yesterday (2024-01-18 7:49:10.493), so it may explain why the query hasn't updated yet. But the same client failed to update its inventory on January 16th even though it was connected to the filewave server that day. The log reads like this: Quote 2024-01-16 8:59:10.014|main|FATAL|CLIENT|Failed to update inventory. Error -99: Connection timed out 2024-01-16 8:59:10.014|main|FATAL|CLIENT|Retrying in 10 second(s)... 2024-01-16 8:59:11.952|Thread (pooled)|FATAL|CLIENT|MS Update: Search failed: Unknown error code -2145123272 2024-01-16 8:59:11.952|main|INFO|CLIENT|finished scan for InventoryScanner 2024-01-16 8:59:21.110|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.125|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.157|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.172|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.172|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.172|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.204|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.204|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.220|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.220|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:21.415|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:23.072|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:23.072|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:31.206|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:31.238|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:41.185|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:41.185|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:48.471|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 8:59:48.514|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:00:00.457|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:00:00.479|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:00:00.498|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:00:00.500|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:00:00.510|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:00:02.124|main|FATAL|CLIENT|Failed to update inventory. Error -99: Connection timed out 2024-01-16 9:00:02.124|main|FATAL|CLIENT|Retrying in 20 second(s)... 2024-01-16 9:00:08.834|main|INFO|CLIENT|[void __thiscall KioskServer::slotUserLogin(const class QString &)] 2024-01-16 9:00:08.834|main|INFO|CLIENT|non threaded scan for InventoryScanner started 2024-01-16 9:01:04.245|main|FATAL|CLIENT|Failed to update inventory. Error -99: Connection timed out 2024-01-16 9:01:04.245|main|FATAL|CLIENT|Retrying in 40 second(s)... 2024-01-16 9:02:26.380|main|FATAL|CLIENT|Failed to update inventory. Error -99: Connection timed out 2024-01-16 9:02:26.380|main|FATAL|CLIENT|Retrying in 80 second(s)... 2024-01-16 9:02:34.566|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:02:34.594|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:02:40.196|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:02:40.214|main|INFO|CLIENT|non threaded scan for NetworkScanner started 2024-01-16 9:03:55.268|main|INFO|CLIENT|non threaded scan for NetworkScanner started Link to comment Share on other sites More sharing options...
Moderators Sean Posted January 19 Moderators Share Posted January 19 With that in mind: How many devices do you have and of which type? Do you use Boosters? Do you use Booster routing? Does the FileWave Central Dashboard show any resource that are being fully utilised? Perhaps the server is being overloaded with requests. Other things that can impact this: API requests Tickle time too low Too many requirement scripts that are never successful Frequent Model Updates Maybe the above will highlight something. Link to comment Share on other sites More sharing options...
Tobias.vonLienen Posted January 22 Author Share Posted January 22 950 Mobile and 700 PC clients Yes, we have 2 boosters Yes, route server messages via Boosters is enabled on all our PC clients No, shows nothing unusal. what do you mean by API requests and how can I check tickle time is standard 120s Haven't noticed it before, but will check it out Recently there have been more model updates as usual, since we're testing something. What do you consider as too frequent? Link to comment Share on other sites More sharing options...
Moderators Sean Posted January 22 Moderators Share Posted January 22 API are usually used for linking 3rd party products, but could be used in scripts to interface with the server. If you haven't configured any of these, then there shouldn't be any in use. Whilst the model is updating, clients will temporarily be unable to communicate with the server. It would only be if you had something designed to automatically trigger lots of Model Updates could this even be a consideration, so it sounds unlikely. With routed messages, things should be good too. Have you enabled DEBUG on the client to see if this highlights something in the client logs? Have you opened a ticket with support? 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now