I am working with pub/sub for the first time and its quite confusing. I just want to receive push notifications on my MVC application whenever I receive an email on gmail account. I have setup the project id (enabled pub/sub API), created a topic with permissions (gmail-api-push#system.gserviceaccount.com) and added a subscriber to that topic, everything from console.cloud.google.com as I don't think I need to setup these from my code everytime.
I am trying to set the delivery type to 'Push into an endpoint URL' with the URL of my choice (I tried to setup localhost/home, also with SSL, then one of my online domains for testing) but keep getting this "generic:3" error on bottom-left. I don't want to use 'Pull' each time as the delivery type.
There isn't a lot of help on this apart from developers.google.com but I'm not getting the reason for this error. Any help would be highly appreciated
Based from this documentation, if you want to push notifications when there are changes to Gmail mailboxes, you need to use the Cloud Pub/Sub API. Be noted that in push delivery, the Pub/Sub server sends a request to the subscriber application, at a preconfigured endpoint. The subscriber's HTTP response serves as an implicit acknowledgement: a success response indicates that the message has been successfully processed and the Pub/Sub system can delete it from the subscription; a non-success response indicates that the Pub/Sub server should resend it.
Usually, generic error occurs when a transaction fails. By default, the API Gateway returns a very basic error to the client when a message filter fails. You can try the workaround in this forum.
Related
I have a dotnet core 3.1 web api application. The app is a gateway to expose various other services that communicate through Service Bus (queues, topics). We're using service bus for asynchronous messaging between services. I dont want any sync communication between gateway and other services.
So, I'm trying to find a way to receive request in controller to for example create a resource and send that command to service bus, then sit and wait.
Meanwhile, service will save command to db and emit event.
Gateway is listening on topic to receive the message and now, somehow, I need to pass this message back to the request in controller that is waiting for this message to finish its own execution.
As far as I know you can't know if the execution of the handler has finish properly by waiting in the controller (as is in your case) in a straight foward way, but, maybe you can do a work arround.
As you know Service bus has a queue or topic where the listener can get the messages sent. But also it has a DeadLetter, where the wrong messages are queued back if any unhandle exception occurs, any message has an internal Id or also your custom body has an Id that you can use to track it and look for it in boths queue or topics. Maybe this can solve your problem, but this is not efficience at all as this is not the desire functionalities of this kind of service, because, in deed, his function is to let you know that your message has been queued, and then you should follow your execution and handle the message in your service.
You're creating your resource asynchronously, so don't try to give the appearance of synchronous behavior. Return an HTTP status code 202 from your API request and let the client query for the created resource at a later time.
Here’s our architecture:
JIRA webhook sends messages to a Java Jersey REST service when issues are assigned.
C# client application registers the username/host machine combo with the Java web service when a user logs into the machine
When the web service receives a message from JIRA, it finds the assignee username and sends the required data to the C# client app on the host machine(s) the user is logged into.
I’ve thought of a couple approaches to solve the web service to client message.
My first is opening a TCP port on the client and having the service send each message directly to it. This is the most straight-forward approach but makes the client a little heavy in that it maintains the list of user assigned ticket data that they can then manipulate (acknowledge or remove).
The other is having the service maintain the data model and the client requests data periodically. This makes the client simpler but then I’d have to implement a polling interval to grab data, and add some POST methods for acknowledging and removing data from the user’s list.
I was looking into different ways to have the client register a channel with the service, like ServiceStackEvents, but I can’t see a way to make that work with a C# client and Java service. Something like that would be perfect. A way for the service to send callbacks or event messages to a client based on a user filter.
If someone has some suggestions or knows of an API to help with this, please post a link so I can dig into it. The POSTs are all working swimmingly, it’s just getting the data back to the clients that I’m struggling with the best approach.
Thanks!
Client polling is not a terrible solution.
But if you want a firewall and proxy friendly duplex protocol, check out WebSockets https://en.m.wikipedia.org/wiki/WebSocket.
I am using SignalR in my application to send messages to different users in a group.
We have the capability that messages can be added/edited or deleted and the same action is sent to all the users in that group via SignalR hub.
All that is working fine.
The issues is one could miss other people actions (message add/edit/delete) which happened during the time when his connection was lost/ internet disconnected or his laptop/machine was off.
After getting connection back or opening the laptop again that user must receive all those missed messages, missed actions which occurred during the time he was offline.
We are storing all clients (client id) of all users in database.
Can anyone give the pointers how to do that?
One solution can be to poll last message id (which has come to ui) to server check if any new message is there but that won't serve the purpose because message could have been edited/deleted at server from other user.
I have already gone through following links
Can SignalR handle missed messages?
Can a SignalR message loss be detected server side?
How to do guaranteed message delivery with SignalR?
Signalr client to retrieve missed messages on reconnect
https://github.com/JabbR/JabbR/issues/699
but none of them is covering the aspect for the entire history which happened during the time user was offline.
For example if you are disconnected in Skype and comes back say after few hrs it pulls all the history of all actions (message added/edited/deleted) that occurred during that time and update it to end user
Since SignalR doesn't povide any guarantees of message delivery - one should solve this by himself.
There are several approaches:
The first is to use message queues (ex: RabbitMQ).
This is the most efficient way to guarantee that message is delivered to client.
But in your case you'll need to combine message queueng with pub/sub way of communication. That can be tricky.
The second way is described in the answer to one of SO posts, that you referenced: Can SignalR handle missed messages?.
Don't send data over signalr, only notifications; then get the data update from the server.
That is my favourite way of client-server notification/update scheme. And I'd choose it in your case.
One solution can be to poll last message id (which has come to ui) to server check if any new message is there but that won't serve the purpose because message could have been edited/deleted at server from other user.
To overcome this you can poll not the last message, but history of actions made in conversation (add/update/delete message actions) since last updated and apply it on the client side.
In a scale-out scenario where one server consists of master+worker endpoints and another server consists of workers, is it safe to call bus.Publish from an endpoint when it finishes handling a given event? (Keeping in mind bus.Publish could be invoked from an endpoint sitting on the worker server).
My initial reaction is that it's not safe since it sounds like the example where you should never call publish from a web server...
We could certainly use the WCF wrapper and call out to a service that exists only on the master+worker endpoint server, but does anyone have any practical experience with this?
Thanks!
Each logical subscriber has a receiving endpoint. If you're using the distributor, this is the distributor endpoint, or distributor queue, if you will. So the subscriber will subscribe to specific events and specify it's receiving endpoint. The publisher will have no idea if it's a single endpoint instance, or if it's a distributor receiving the message.
The distributor will then send the message to a worker that is ready to process the message.
This is explained in more detail and with some clarifying images on this page: http://docs.particular.net/nservicebus/scalability-and-ha/distributor/publish-subscribe
In the end, we made our web apps "send-only endpoints" which essentially means they simply send commands directly to an endpoint via a chosen transport (in our case MSMQ). Once we need to scale, we will eventually implement "Sender Side Distribution" rather than utilizing the distributor.
From the NSB support team: "If you add more endpoints, Sender Side Distribution is the way to go. It acts as a round-robin mechanism running on the sender side which would send messages to a different 'worker' endpoint when you scale out."
https://docs.particular.net/transports/msmq/sender-side-distribution
If you only need to fire-and-forget messages from a website or some other app/service, I'd recommend this approach - it's quite simple.
We have an existing Websphere MQ Queue Manager (running fine, no issues). This has for each "method" a pair of queues: Request and Response.
We'd like to put a web service front end over this for the benefit of some apps we have that cannot call MQ but can call web services.
Of course, Web Services can be synchronous but our MQ is async...and I am not sure how to get around this.
Example:
App calls webservice...web service waits for response.
Webservice calls MQ Request queue and puts the message.
of course, the response will be on a different channel...so my thinking is that the webservice would have to read all the messages on the queue and only remove the correct one (by some identifier such as GUID).
Has anyone got any previous design knowledge on solving this?
The web service does need to read all the response messages, you can perform a correlate get. When the request is put on the request queue you use the request message id and wait on the response queue for the response message with the correlation id. MQ handles this very efficiently.
Here is another stackoverflow answer that shows some code for performing a correlated get
Issue in Correlating request message to resp message in Java Client to access MQ Series