B4J Question Publish subscribe mechanism opinion needed

I have put my thought in action and i have created my own pub sub mechanism using a code module with global threadsafe maps for keeping channels and subscribers and also for messages, i am using a backgroundworker which acts as a broker/router to process the message queue ... small tests that i have done are looking good.

Opinions/advices are still welcome

Is probably the way to go.

mindful said:

Hello, I have a project in b4j with jserver(websockets) and abmaterial and I am in the need of some publish and subscribe mechanism. Basically I want to: when a client(browser) make a modification (create, remove, update, delete) to something I want that modification to propagate/spread to the other connected clients. Kind of what facebook does when someone hits the like button on a post that like will appear to all other users viewing that post.

What are my options ?

I have thought of creating my own mechanism using a combination of threadsafe maps + list in a module and using a server background worker to process the message queue ...

Is this the right way to go ? Will mqtt work as a publish subscribe in a server with websockets as all clients are from the server ?

Click to expand...

What you're describing is a real-time database. That's how Firebase (formerly Envolve) got their start specializing in online chat. See the history section of the Firebase Wikipedia article

Real-time database
https://en.wikipedia.org/wiki/Real-time_database

Firebase
https://en.wikipedia.org/wiki/Firebase

@stanmiller thanks for your suggestion ... More or less I wanted to know if B4J or websockets had a publish or subscribe mechanism ... So let's take the following scenario: One of my users setups daily/weekly reports, so the next report will be schenduled for generation the next day ... As I will verify and generate reports using a server backgroundworker which check every hour if it has any 'job' to process I need some kind of publish/subscribe mechanism that when the report will be generated I will publish a message/notification to a channel where all users that find that report usefull (all users from an account) and are connected so they can update their view (put a badge on the topbar notification item and create a container in the notification extra sidebar) in realtime.

And as I said I created my own publish and subscribe mechanism using a code module with global threadsafe maps (a map for channels and subscribers and a map for messages). So when a user(page/server websocket class) subscribes to a channel it will be added to the subscribers list for the given channel and when a user or the server itself publish a message for a channel this message will be added to the message ts map (which acts like a queue). After this comes in the scene the queue processor - a server background worker that checks every second if it has any new messages, if it has then I use CallSubDelayed to call the sub from the subscriber that can handle the message - so it can run in the subscriber thread. This is how I done it (more or less ) and I must say it is working surprisingly well as I get the view (what users see in browser) updated with realtime data (this is what I needed).

This mechanism is usefull for many things like chat applications, collaborative applications (where one user makes a modification and the other users must see in realtime), showing server statistics with real time numbers (this is something that i will definitely need), etc... also using this kind of mechanism will need to have all the communication optimized as much as possible because as the user base will grow so will the bandwidth needed and used - I am long way from finsihing my project )

Hi mindful, great work!
May I ask you why you didn't choose to use MQTT? TIA

udg

@udg I haven't 'experimented' with mqtt, yet .... and as mqtt is using tcp sockets to communicate i considered a disadvantage for what I needed as all the 'subscribers' are server internal websockets classes so using mqtt each server websocket class would had to have a private mqtt client that would connect using tcp sockets to the mqtt broker (this could be an advantage if you have a cluster of servers for your clients, as the publish subscribe mechansim will work even if you have one client connected to one server and another one to other server because both servers will use the same mqtt broker, but as all my users connect to the same server i needed an internal publish subscribe mechanism)