I want to implement push notification in java so please help me out
1-Each time a new record(Message) pushed into data base(due to event created by some other user), a push notification should be sent to specific Logged in user automatically.
2-Content of the push notification should be the message present in the db.
3-If there are multiple messages, then the user should receive them one by one in a queue fashion.
4-Most important thing is the logged in user need not have to trigger any event to get notification, user should receive it automatically throughout the session.
You could use Server Sent Events. Java provides SseEmitter to send timely notifications.
You can use EventSource API in JavaScript to trigger the SSE event stream and in the server-side, loop the database query code which is wrapped by an ExecutorService - which can spin of separate thread based on the initialization.
Put SSE timeout to -1 for listening for an infinite amount of time.
Please note this answer is only a hint. Use these to explore more from the internet.
Related
I have a task to fetch data from server at start if application. For purpose i am calling an api by asynctask for notification codes and parse data. The data can go upto 60000 notification codes.
For each notification code i have to call different apis to get data. After performing operation i need to again call an acknowledge api to tell server notification has been acknowledged. So next time when getting notification code it dont repeat.
So in the case i have to call approximately 60000 asynctask for operation and 60000 for acknowledgement. Do each operation for different api urls and then Acknowledge each operation for different url simultaneously
My app is working when notifications are below 1000 but for more than that notification it stucks.
Please anyone can guide what's the best way to implement this.
I am building a chat app, and like Whatsapp, I need to provide users the facility to save their messages as undelivered when internet connectivity is OFF, and as soon as the internet is back then that data should be retried to be sent to the receiver.
But, in case I scheduled a write operation using Firebase .setValue(), then how could I cancel that process in case the user changes his mind and doesn't want that message to be sent, or in technical terms does not want to setValue(), how could I stop that ongoing write.
As I understand from your scenario, the problem arises when the device is offline and you want to let the user the possibility to delete the message, so it cannot be displayed once it regains connectivity. Because the setValue() method returns a Task<Void> object and because I don't see any cancel method in this class, the only thing to do it to simply remove the message. In this case, when the user is back online, no other users will see the deleted message.
On the other side, it's true that there is a chance in which the user sends the message and right after that he loses connectivity. Even if there was a cancel method, you would have nothing to cancel, as the message is already set on the server. Again, the single option that you have is to delete the message. The delete operation will remain in queue until the device regains connectivity and right after the synchronization the message will be deleted.
Besides that, remember to set the persistence enabled, because it's not enabled by default:
setPersistenceEnabled(true);
My programme is a notification service, it basically receives http requests(client sends notifications) and forwards them to a device.
I want it to work the following way:
receive client notification request
save it to the database(yes, i need this step, its mandatory)
async threads watch new requests in database
async threads forward them to the destination(device).
In this case the programme can send client confirmation straight away after the step 2).
Thus, not waiting for the destination to respond(device response time can be too long).
If I stored client notification in memory i would use BlockingQueue. But I need to persist my notifications in db. Also, I cannot use Message Queues, because clients want rest endpoints to send notifications.
Help me to work out the architecture of such a mechanism.
PS In Java, Postgresql
Here are some ideas that can lead to the solution:
Probably the step 2 is mandatory to make sure that the request is persisted so that rather it will be queried. So we're talking about some "data model" here.
With this in mind, if you "send" the confirmation "right away after the step 2" - what if later you want to do some action with this data (say, send it somewhere) and this action doesn't succeed. You store it on disk? what happens if the disk is full?
The most important question is what happens to your data model (in the database) in this case? Should the entry in the database still be there or the whole "logical" action has failed? This is something you should figure out depending on the actual system the answers can be different.
The most "strict" solution would use transactions in the following (schematic) way:
tr = openTransaction()
try {
saveRequestIntoDB(data);
forwardToDestination(data);
tr.commit();
} catch(SomeException ex) {
tr.rollback();
}
With this design, if something goes wrong during the "saveRequest" step - well, nothing will happen. If the data is stored in db, but then forwardToDestination fails - then the transaction will be rolled back and the record won't be stored in DB.
If all the operations succeed - the transaction will be committed.
Now It looks like you still can use the messaging system in step 4. Sending message can be fast and won't add any significant overhead to the whole request.
On the other hand, the benefits are obvious:
- Who listens to these "notifications"? If you send something and only one service should receive and process the notification how do you make sure that others won't get it? How would you implement the opposite - what if all the services should get the notification and process it independently?
These facilities are already implemented by any descent messaging system.
I can't really understand the statement:
I cannot use Message Queues, because clients want rest endpoints to send notifications.
Since the whole flow is originated by the client's request I don't see any contradication here. The code that is called from rest endpoint (which is after all is a logic entrypoint that should be implemented by you) can call the database, persist the data and then send the notification...
Through Hazelcast's Java client I am able to successfully add an EntryListener and the listener is called as expected when entries are added or updated. So far so good.
But sometimes the client application becomes disconnected from the cluster. When this happens the client often reconnects automatically and the client has to once again add the listener. But during this brief period (between disconnection and adding the listener again), there is a chance that events are missed.
Another time that events maybe missed is if the client needs to be restart.
Is there a way to guarantee that an EntryListener receives all events?
Event listeners work in a fire&forget manner, so there is no way to receive past events.
However; there's ReliableTopic, which stores the last N events in a ringbuffer. And if you listen it with a ReliableMessageListener, it can store the event id's locally and resume from the last received event in case of a disconnection etc. Please check out the interfaces of those two.
Could anyone please elaborate a bit on watermark and its use with respect to recreating subscription using push notification in EWS application?
I read the Microsoft provided information regarding it. But I did not get to understand accurately its usage.
It is explained as:
"The Watermark element represents an event bookmark in the mailbox event queue."
Does it mean that for every event we get new or different watermark in the notification?
Also:
"If a Subscribe request contains a watermark, the subscription is created from the watermark forward."
Does it mean that if we subscribe using a watermark previously sent to us, we can get or identify all the events occurred after it?
Does it mean that for every event we get new or different watermark in the notification?
Yes as the Events are delivered to you client you will get the Water-Mark associated for that event in the Queue.
Does it mean that if we subscribe using a watermark previously sent to us, we can get or identify all the events occurred after it?
Yes if you use a previous watermark your client is telling the server to send the events that occurred after that watermark. Watermarks are valid for 30 days but there are events that can trigger them to become invalid eg
https://blogs.msdn.microsoft.com/exchangedev/2008/07/24/transitioning-to-exchange-web-services-notifications/ . So you need to consider that if you using them for synchronisation.