I'm building a website using springboot as RestAPI and angular in frontend. Also, i will be getting data in my rest(consumer) from around 40-50 swing standalone apps(producers) through kafka. I need to implement online status for those swing apps. Basically, i need to know when and which one of swing apps went offline or back online. Is there a way to implement this? If this is impossible with kafka can you recommend something else for communication?
Clarification:
By online status i mean whether device on which swing app is installed has internet connection or not.
Swing app will be installed on around 40-50 devices on remote locations.
Eventually i got rid of kafka and used websockets. Using WebSocketHandler i had information when certain standalone app is connected or disconnected. When standalone app looses internet connection server is notified relatively quickly (within 60 seconds). Keep in mind that in my case standalone app will be sending data quite often. If this is not the case for you then i recommend looking for some other solutions and taking a look at #OneCriketeer comment regarding Nagios.
Related
I just got started with Java Web Application Development and I've been developing a Web Application with Java Servelts using Apache Tomcat where customers can book appointments with hair stylists. Now I want to add a feature where stylists are notified by a push notification in real time once a client makes an appointment. I did my research and I found out the following ways:
Long Polling
Server Sent Events/ Event Source
Web Sockets
Since the necessary communication is asynchronous from the server, I feel that the Server Sent Events would be the right choice.
I came up with an idea where the book event generates a notification which is stored in a separate table. A thread monitors the data source for any new notifications and notifies the targeted receiver once a new nofication is found.
The issue I am facing here is how to identify the necessary active client out of several clients and target the data to it.
I've been looking everywhere in the internet and I couldn't find any Java Servlet and Tomcat implementations for reference.
Is it possible to implement my idea using just Servlets in a Tomcat container?
If there is a better approach to this problem, please let me know.
I've been studying App Engine for a work assignment which is to implement a chat service similar to Facebook's desktop page chatting. I had previously implemented something similar but since it ran on proprietary servers where there was no limit to traffic and technologies, I'm not sure that same implementation will work on App Engine.
Some things to notice:
This is for a web page/app. There is no specific messaging client application
App Engine doesn't support websockets
App Engine doesn't allow threads to outlive their requests (meaning I can't hold a background thread that awaits for new messages and pushes them to the user)
App Engine wants to service requests in a matter of seconds. I had thought of using long polling like facebook does but I'm not sure if this will be allowed
Is long polling every 30 seconds even an option? I'm afraid it massively increases my traffic costs...
I looked at XMPP but I think it doesn't really apply to web applications. Also I think I read somewhere in the docs that it is not/will not be supported anymore?
I'd like some advice on how I should go about this. I'm going to use Cloud Datastore for storage and I was hoping to implement this as a simple RESTful microservice to be honest but I'm not sure anymore.
You can merge goole app engine with google firebase to easily achieve a realtime chat application
you can access the realtime database on firebase using only javascript to update and display chats
I'm developing an Android app that requires 2 (or more) devices to communicate with each other.
I tried using Google Cloud Messaging but I was disappointed to find out that the GCM max capacity is 100 messages, so it is broken and does not fit my requirements.
I was thinking about java sockets. Every device will open a new socket (or keep its socket open) and communicate with a group of sockets (devices).
In order to communicate this way I need a server-side app that can send messages to the client (android device). So I figured out that HTTP or web-service won't help me. Am I right?
What is the best way for me to implement such a server-side app?
You can refer to this question I previously asked and implemented. It was for implementing my own Notification mechanism but it equally (or even more) applies to chatting applications since message queues perfectly fit that usecase.
Building an Android notification server
I ended up not doing it and using GCM at the end but I did have a fully working solution using ActiveMQ and Paho. You can research them both and understand their inner workings. It's easy in principle and definitely possible but the problem is, you may not be able to do this for iOS or WP as it requires running a service in the background (in case your app is not open and you want to make sure the messages are at least sent in a notification).
The possible solution to that problem would be to use both the notification service (GCM or equivalent) for background notifications and then using your MQ for actual communication but I decided that was too much for my project.
If you look at Paho, it will have a fully working MQTT solution that will work even if the phone is not "online" (sleeping or otherwise) and there are plenty of samples for ActiveMQ and drivers for multiple programming languages.
I think this solution is much better than having open sockets between two apps, at least because they allow you to persist messages and guarantee delivery which is an important aspect for a chatting application.
As it is said by kha, choose one of the message queue protocols is the best solution. 3 reasons in brief,
Delivery guaranteed regardless of temporary offline or long latency.
As simple as subscribe / publish, no worry about transport layer any more.
Broker available online. You save time and money for setting up your own.
For mobile devices like in your case, I'd prioritize MQTT too. It's lightweight and stable. If you are totally new to message queue or MQTT, refer to this documentaion and example code
I have a very basic design of my entire application, where several users with my app on there android devices commits data to the server (I have used REST web services(java) + postgresql as my server) through HTTP post request from the android application. I am successful in achieving this and app runs absolutely fine. Now i want to implement a scenario where any change(CRUD operations) on my db on server should create a notification on my users android device. How should i achieve this with my server design unchanged? I have looked into Google Cloud Messaging, but could figure out the server implementation.
For now i have implemented db triggers on postgresql and able to get control back into java code using Notify/Listen feature of postgresql. From here i need to connect to android device. How can this be achieved. Is Google Cloud Messaging the only way? I have not seen any insert/update statements in there server implementation. Could anyone please guide me on this?
either you can use GCM or implement a Socket at server end and open a socket connection from mobile but this approach may add some additional processing overhead because it will create a daemon thread to listen socket port from mobile device.
You should use native library (NotificationManager etc.), here you can find a great tutorial.
My Advice is for you to use GCM. GCM normally takes a maximum of 4kb, so you could have your own defined "commands". You could use them to determine the requests on both ends, ie on android app and the server end. A php script on the server would help you in this.
I am working on an app where by the android app sends messages to the server via POST and the server forwards the message to the appropriate user via GCM. In my case I have very many things to share so in that case I am using commands, for example if it is a new incoming message I send a GCM to the app with one variable as the command and the rest as the data. On the android app I use the command variable to determine what to do with the data.
Kindly avoid that socket advice, it will have your app drain the battery to sustain the open socket , besides you don't have to re-invent the wheel while Google servers already has it
A friend and I are currently working on a turn-based game with chat with both desktop browser and Android clients, with Google App Engine as the server.
We're using the Java API for GAE and using HTTP for communication with the server. We've implemented simple chat functionality, and we're getting undesirable latencies 1-3 seconds from both the browser and Android clients while just posting simple one-word chat messages.
My friend thought it would be best to use XMPP instead of HTTP, but we want to use a Google Accounts cookie for authentication from the Android client, and according to the GAE documentation, XMPP clients cannot use a Google Accounts cookie and must use the user's password.
Does anyone have any suggestions as to where the latency might be coming from, how to troubleshoot it, and/or what to do about it?
Also, is anyone aware of any opensource implementations of chat (or something similar) on GAE done in Java? Can't seem to find any.
One way to analyze the situation would be to use Wireshark to look at the network traffic during the delays.
You don't say how your chat messages are getting from one JVM to the other. If you're using the datastore, maybe try memcache?
Also, startup time is often an issue; app engine starts and stops JVMs all the time, particularly for a low-traffic app. A way to diagnose this is to reload the page a bunch of times (send more messages) and see if it gets faster after a while. It should be pretty easy to tell the difference in the admin console logs.