Looking at actual lobby-server tcp connection: reactive programming here allows us to move away from a constantly polling io thread which eats a lot of CPU waiting (RAM is almost completely irrelevant here). Therefore reactive programming actually is a good match for UI programming which is the reason why web frameworks such as React and Angular was ahead of the Java ecosystem years before (well apart from the fact that JavaScript only allows one thread they needed a better solution). It also allows additional improvements such as better unit test supports and better handling and mixing of separate async operations than the Java 8 library can.įurthermore the client by itself is per definition already forced to run stuff in background thread and schedule it elsewhere because it has a GUI with a main thread and we need to be particularly cautious not to ever block this thread.
DVR CLIENT V1.0.3.7 CODE
This code was already pretty ugly and complex to understand and using Project Reactor actually can make the code more consistent and easier to read. And in some cases it's worth it and in others it's not and I would not introduce it without good arguments.īut that "reactive is complex"-bashing you do here doesn't apply at all, because the client already tries to be asynchronous by applying the crappy Java 8 CompletableFuture logic everywhere it touches API calls. I will not argue that in general replacing classic synchronous blocking code with reactive code is increasing the code complexity.
DVR CLIENT V1.0.3.7 DRIVER
Less memory consumption due to less threads is one of many benefits, but it is not the main driver behind moving to reactive patterns. Furthermore if you would have reviewed the changes you would have spotted that this change goes beyond just introducing reactive patterns. You take the time to spit out unqualified critics on a topic by reading a short summary of the changes obviously without a) even have the slightest understanding what reactive is about or b) how it affects the client architecture overall. How many memory blocking code was consuming per call? I dont mind if you will be rude(actually your last post is toxic so whats the difference) There should be a reason for switch to non blocking approach so just write it. This is a big change so hopefully no bugs were said in Client v1.6.0: This is a rework of the client backend so that it is entirely non-blocking and removes redundant classes which should result in less resources being used and easier to maintain code base. Rework Client backend to be non-blocking and remove unnecessary boilerplate This will fix the issue where the fafdevelop exe needs to be downloaded on each game start
DVR CLIENT V1.0.3.7 FULL
However player based searches need to have the full and exact name of the playerĬache files on download and keep downloaded version This will mitigate the slow search some players have been experiencing in the vault since the recent server update. Use exact search for player name in replay vault Once launched this will enable the client to connect and detect when services are down automatically. This should result in fewer threads and thus less resource usage by the client.Īdd ability to communicate with stat ping service This will use a non-blocking call to retrieve data from the api. Use Reactive based web client for api calls Use a utf-8 encoded connection to the server over the older utf-16 connection.
Use UTF-8 connection to the lobby server The Server Status page has now been removed and is no longer updated so it has been removed from the front page of the client. As the new PRs are merged they will be added here. This topic is meant to introduce the new features and updates that are being added to the client for version v1.6.0.
0 kommentar(er)
