We are implementing a chat infrastructure with using ejabberd-16.08 and we've decided to use mod_interact(https://github.com/adamvduke/mod_interact) for sending request to our webservers while the receipant user is offline (so we can send them push notifications)
However when I integrate mod_interact with ejaberd and send a message to one of my offline friends in my roster, I saw that mod_interact sends mod_unavailable message instead of mod_offline message. (I want mod_interact to send mod_offline message because only mod_offline has the proper information to send push notifications)
So I wonder whats the difference between beeing online and beeing unavailable and how can we set that.
P.S: The user I'm trying to send message(Which seems unavailable) was disconnected from server(not specificaly set his/her presence to unavailable)
Thanks
When the user gets offline means he is disconnected form the server and unavailable behaviour is same as offline .if you want to customize the behaviour of presence unavailable you can. You can visit here to know more.
In XMPP there's nothing called offline.
User status could be,
unavailable -- Signals that the entity is no longer available for communication.
subscribe -- The sender wishes to subscribe to the recipient's presence.
subscribed -- The sender has allowed the recipient to receive their presence.
unsubscribe -- The sender is unsubscribing from another entity's presence.
unsubscribed -- The subscription request has been denied or a previously-granted subscription has been cancelled.
probe -- A request for an entity's current presence; SHOULD be generated only by a server on behalf of a user.
error -- An error has occurred regarding processing or delivery of a previously-sent presence stanza.
unavailable means user gone offline. But if an online user set custom status as unavailable you also receive unavailable status but in this case user is actually online.
Note : You can use probe to get user's actual status.
Related
Curious, if there is way to avoid skipping messages sent from Telegram Bot while web-server that accepts Webhooks is down (because of redeploy, failure or maintenance).
When you use polling - Telegram API sends messages starting from last retrieved and no message are skipped.
But how to be with Webhooks? Use polling or there are some special mechanism for that?
Telegram keeps the incoming message for 24hrs, if you are Webhook is down (ie redeploying) then the message will be delivered once it is again online.
It works on Heroku for example where your Dyno is down: as soon as it starts the Chatbot will register again with Telegram and will receive the messages still available in the queue.
There are two mutually exclusive ways of receiving updates for your bot — the getUpdates method on one hand and Webhooks on the other. Incoming updates are stored on the server until the bot receives them either way, but they will not be kept longer than 24 hours.
See Telegram documentation for more details.
I had the same problem recently but I just resolved it by when the server starts save the started time to a variable and then use Telegrambot.Message.date and compare the time if it was sent before the server start time or not.
We have a simple application, who upon every update of an entity sends out a notification to SNS(it could very well have been any other queuing system). Clients are listening to these notifications and they do a get of updated entity based on these notifications.
The problem we are facing is, when clients do a get, sometimes data is not replicated and we return 404 or sometimes stale data(even worse).
How can we mitigate this while sending notifications?
Here are Few strategies to mitigate this with pros and cons
Instead of sending notification from application send notification using database streams
For example dynamodb streams ans aws lambda. This pattern can be useful in the case of multiregion deployment as well. where all the subscriber, publisher will subscribe to their regional database streams. And also atomicity of sending message and writing to database is preserved. And we wont loose events in the case of regional failure.
Send delayed messages to your broker
Some borkers like activemq and sqs support this functionality, but SNS does not. A workaround for that could be writing to sqs queue which then writes to sns. This might be a good option when your database does not support streams.
Send special error code for retry-able gets
Since we know that eventual consistency is there we can return special error code to clients, so that they can retry based on this error code. The retry strategy should be exponential backoff. but this may mean giving away your problems to clients. Also we should have some sort of versioning in place.
Fetch from another region
If entity is not found in the same region application can go to another region or master database to fetch it. NOTE Don't do this. as it is an anti pattern. I am mentioning it here just for the sake of completion.
Send the full entity in message
If entities to be fetched by rest service is small and there are no security constrain around who can access what, we can send the full entity in message. This is ensure that client don't have to do explicit fetch of it every time a new message is arrived.
I have a server, and multiple clients (web & mobile). When my users log in, I want to start sending them notifications about the content they follow. When they log out, I want to stop sending them notifications.
I've found many Stack Overflow questions that are similar to mine, but none have been completely answered.
The closes to my question was this other question where the accepted answer is to call deleteInstanceId() when the user logs out, which seems like the most solid solution, but in the comments someone copy pasted from the (GCM) docs that "Developers should never unregister the client app as a mechanism for logout or for switching between users". I wasn't able to find the same notice in the new Firebase docs, but I assume that it's the same concept: the InstanceId is not supposed to be user related.
The only alternative I've found, is to send a "signOut" request to my server, with the instanceId, and my server needs to remove the associated instanceId from the user account.
But what if that API call doesn't go through? This seems to be quite a fragile solution.
So this is what I would do now:
Send the instanceId to my server when the user authenticates
Make sure that this same instanceId is not used by another user, since this could happen when the other user logged out on the same device, but the API call didn't go through
When sending notifications, send them directly to the registered instanceIds (initially I had planned on using topics, but in combination with handling my tokens, this seems even more fragile).
When the user logs out, send a signOut request to my API, and remove the instanceId from the user.
Your question seems to just be seeking validation for a design, which really isn't the purpose of Stack Overflow. The Firebase subreddit might be a better alternative for drumming up conversation around the problem.
But I will say that if it works for you, then run with it. Consider also sending the target users's UID in each message, and have your app compare that with the currently signed in user in order to determine if it reached its correct destination. Send a message back to the server if it's not in order to correct the problem.
Scenario
I am building courier service system using Microservices. I am not sure of few things and here is my Scenario
Booking API - This is where customer Place order
Payment API - This is where we process the payment against booking
Notification API - There service is responsible for sending the notification after everything is completed.
The system is using event-driven Architecture. When customer places booking order , i commit local transaction in booking API and publish event. Payment API and notification API are subscribed to their respective event . Once Done Payment and notification API need to acknowledge back to Booking API.
My Questions is
After publishing the event my booking service can't block the call and goes back to the client (front end). How does my client app will have to check the status of transaction or it would know that transaction is completed? Does it poll every couple of seconds ? Since this is distributed transaction and any service can go down and won't be able to acknowledge back . In that case how do my client (front end) would know since it will keep on waiting. I am considering saga for distributed transactions.
What's the best way to achieve all of this ?
Event Sourcing
I want to implement Event sourcing to track the complete track of the booking order. Does i have to implement this in my booking API with event store ? Or event store are shared between services since i am supposed to catch all the events from different services . What's the best way to implement this ?
Many Thanks,
The way I visualize this is as follows (influenced by Martin Kleppmann's talk here and here).
The end user places an order. The order is written to a Kafka topic. Since Kafka has a log structured storage, the order details will be saved in the least possible time. It's an atomic operation ('A' in 'ACID') - all or nothing
Now as soon as the user places the order, the user would like to read it back (read-your-write). To acheive this we can write the order data in a distributed cache as well. Although dual write is not usually a good idea as it may cause partial failure (e.g. writing to Kafka is successful, but writing to cache fails), we can mitigate this risk by ensuring that one of the Kafka consumer writes the data in a database. So, even in a rare scenario of cache failure, the user can read the data back from DB eventually.
The status of the order in the cache as written at the time of order creation is "in progress"
One or more kafka consumer groups are then used to handle the events as follows: the payment and notification are handled properly and the final status will be written back to the cache and database
A separate Kafka consumer will then receive the response from the payment and notification apis and write the updates to cache, DB and a web socket
The websocket will then update the UI model and the changes would be then reflected in the UI through event sourcing.
Further clarifications based on comment
The basic idea here is that we build a cache using streaming for every service with data they need. For e.g. the account service needs feedback from the payment and notification services. Therefore, we have these services write their response to some Kafka topic which has some consumers that write the response back to order service's cache
Based on the ACID properties of Kafka (or any similar technology), the message will never be lost. Eventually we will get all or nothing. That's atomicity. If the order service fails to write the order, an error response is sent back to the client in a synchronous way and the user probably retries after some time. If the order service is successful, the response to the other services must flow back to its cache eventually. If one of the services is down for some time, the response will be delayed, but it will be sent eventually when the service resumes
The clients need not poll. The result will be propagated to it through streaming using websocket. The UI page will listen to the websocket As the consumer writes the feedback in the cache, it can also write to the websocket. This will notify the UI. Then if you use something like Angular or ReactJS, the appropriate section of the UI can be refreshed with the value received at the websocket. Until that happens user keeps seeing the status "in progress" as was written to the cache at the time of order creation Even if the user refreshes the page, the same status is retrieved from the cache. If the cache value expires and follows a LRU mechanism, the same value will be fetched from the DB and wriitten back to the cache to serve future requests. Once the feedback from the other services are available, the new result will be streamed using websocket. On page refresh, new status would be available from the cache or DB
You can pass an Identifier back to client once the booking is completed and client can use this identifier to query the status of the subsequent actions if you can connect them on the back end. You can also send a notification back to the Client when other events are completed. You can do long polling or you can do notification.
thanks skjagini. part of my question is to handle a case where other
microservices don't get back in time or never. lets say payment api is
done working and charged the client but didn't notify my order service
in time or after very long time. how my client waits ? if we timeout
the client the backend may have processed it after timeout
In CQRS, you would separate the Commands and Querying. i.e, considering your scenario you can implement all interactions with Queues for interaction. (There are multiple implementations for CQRS with event sourcing, but in simplest form):
Client Sends a request --> Payment API receives the request --> Validates the request (if validation fails throws error back to the user) --> On successful validation --> generates a GUID and writes the message request to Queue --> passes the GUID to the user
Payment API subscribes the payment queue --> After processing the request --> writes to Order queue or any other queues
Order APi subscribes to Order Queue and processes the request.
User has a GUID which can get him data for all the interactions.
If use a pub/sub as in Kafka instead of Kafka (all other subsequent systems can read from the same topic, you don't need to write for each queue)
If any of the services fail to process, once the services are restarted they should be able to pick where they left off, if the services are down in the middle of a transaction as long as they roll back their resp changes you system should be stable condition
I'm not 100% sure what you are asking. But it sounds like you should be using a messaging service. As #Saptarshi Basu mentioned kafka is good. I would really recommend NATS - although I'm biased because that's the one I work with
With NATS you can create request-reply messages to interface between client and booking service. That's a 1-1 communication
If you have multiple instances of each of your services running, you can use the Queuing service to automatically load balance. NATS will just randomly select a server for you
And then you can use pub-sub feeds for communication between all of your services.
This will give you a very resilient and scalable architecture, and NATS makes it all incredibly easy
I implemented a GCM push notification service that runs on my computer (at least during development).
To do that, I basically format and send requests to https://android.googleapis.com/gcm/send.
For authentication, I obviously used a server key I generated on the Google Developers console.
I tested it and it works perfectly (the devices receive the push notification, and it's actually damn fast).
I send those push notifications several times in the day, but yesterday I faced a situation were the request sending returned a 401 (which stands for authentication required). My request was exactly the same as usual. I retried 4 times with the same result then suddenly, it worked again and returned a 200.
I'm at loss trying to understand why this happens. According to this documentation, 401 is only supposed to happen if:
Authorization header missing or with invalid syntax.
Invalid project number sent as key.
Key valid but with GCM service disabled.
Request originated from a server not whitelisted in the Server Key IPs.
None of these conditions have changed between the different calls.
Is there some kind of threshold or quota that might explain this ? Or is there a guideline regarding what to do when this happens ?