Initial (not cluster safe) websocket change watcher implementation.

[tetious]

This is a WIP PR of the discussed (#149) web socket based change stream thingie. I have tested it lightly via Postman, so you can play with it now, but I'm sure there are plenty of ways to break it. 😄

You can connect like this: ws://USERNAME:PASSWORD@localhost:2480/ws and send the following two messages:
(for subscribe, type and changeTypes are optional)

{"action":"subscribe", "database":"DATABASENAME", "type": "TYPENAME", "changeTypes": ["create", "update", "delete"]}
{"action":"unsubscribe", "database":"DATABASENAME"}

Still to come:

• Documentation.

---

What does this PR do?
A WIP websocket based change stream. To be documented.

Motivation
See discussion #149.

Checklist
[x] I have run the build using mvn clean package command
[x] My unit tests cover both failure and success scenarios

[lvca]

Thanks, @tetious for your PR! Your code is very clean, even using the stuff available in the newer releases of Java, I'm surprised!

You can find my comments in the files as a review.

About using var we never did that because we were undecided if making everything compatible with Java8+, but we already have taken that decision, the minimum version is Java11, so using var is welcome and frankly suggested from now on to have more compact, less boilerplate code.

About the location, I think com.arcadedb.server.http.ws is the right place.

Good choice to let users subscribe to a single event. This is definitely more efficient and only the messages you're interested in are sent over the network.

[tetious]

Thanks, @tetious for your PR! Your code is very clean, even using the stuff available in the newer releases of Java, I'm surprised!

Thanks very much for the excellent, detailed feedback!

I'm a C#/Typescript guy mostly, and though I dabble widely, I haven't looked at Java since the Java 6 days. Things have improved so much since then! I still wish properties were a thing, though. 😄

I'll update the PR soon!

[lvca]

@tetious thanks for all these changes. it's almost perfect. I've added a few comments. Thanks also for the initial test and the client class to make easier writing additional tests!

[tetious]

it's almost perfect. I've added a few comments.

Great to hear! I don't see your new comments, though. Maybe github ate them?

I'm hoping to finish my todo list tonight and then possibly this will be ready.

[lvca]

Sorry, I forgot to press "Review Changes"

[tetious]

I think this is nearly there. Still to do:

• Write tests for error handling and a few other edge cases.
• Documentation.

I'm running into a problem that I think might be some kind of race in the Listener logic. Most of the time, the first test I run in WebSocketEventBusIT will throw the following exception:

java.lang.NullPointerException
	at com.arcadedb.database.JSONSerializer.map2json(JSONSerializer.java:37)
	at com.arcadedb.database.MutableDocument.toJSON(MutableDocument.java:88)
	at com.arcadedb.server.http.ws.ChangeEvent.toJSON(ChangeEvent.java:28)
	at com.arcadedb.server.http.ws.WebSocketEventBus.lambda$publish$1(WebSocketEventBus.java:49)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at com.arcadedb.server.http.ws.WebSocketEventBus.publish(WebSocketEventBus.java:46)
	at com.arcadedb.server.http.ws.DatabaseEventWatcherThread.run(DatabaseEventWatcherThread.java:56)

It appears as though map is null, but I don't really understand why. Maybe I'm using toJSON wrong on the record?

It seems to be repeatable most of the time. Subsequent tests work fine, and reordering or running tests individually show it is always the first that fails.

Thoughts?

[lvca]

I was able to reproduce the NPE. Working on it.

[lvca]

Fixed. I pushed the fix in this branch, now the test always passes. Thanks for discovering it.

[tetious]

I believe this is ready for a final review!

I will write up some documentation tomorrow and submit a PR in the docs repo.

[lvca]

Thanks, it's a high-quality contribution! I just wrote some comments/questions in the code, but for me, once git your answers and maybe little changes if needed, it's ready to be merged

[tetious]

I can't seem to repro the test failure locally, but I increased the timeout further and am now properly catching the null message case. Maybe this will work, but if not, maybe additional insight will appear. :)

[lvca]

Trying to run the tests on my PC.

[lvca]

Everything is fine on my PC. I guess we should extend the timeout, but 5s is already pretty long. If those tests will fail often we'll look into it. Thanks so much, @tetious, and congratulations on this big contribution!