I have a simple ZMQ 3.2 publisher which sends out messages and there are N number of subscribers that connect and disconnect to this publisher.
Is there any way in which the publisher can have details(IP, Name, Type... etc) of the subscriber that connects to it?
Related
If multiple subscribers share the same pull subscription, when a message arrives at on subscriber, but it takes too long for the subscriber to ack the message, will the message be resent to the same subscriber or other subscribers? What if the subscriber dies before ack, which subscriber will the message be resent to?
Once a message that was delivered to a subscriber expires, it immediately becomes eligible for redelivery. Note that the message may or may not be delivered to the same subscriber binary; Cloud Pub/Sub gives no guarantees on “subscriber affinity/stickiness”.
In the same manner, if the subscriber binary dies before the ack can be sent, the message will be redelivered to another binary, after the ack expiration deadline.
Just wondering does RDBMS like mysql, oracle, sqlserver support using triggers to fire the update events to a message queue?
In PostgreSQL call pg_notify('mychannel', 'my message'); in a trigger
Your message queue, or an intermediary component, would call LISTEN mychannel on a connection to the PostgreSQL database, and send a message to the queue.
Looks like there is an extension to publish directly from PostgreSQL to an AMQP message queue (though not active):
https://github.com/omniti-labs/pg_amqp
If using Oracle use AQ (Advanced Queuing) http://docs.oracle.com/cd/B10501_01/appdev.920/a96587/qintro.htm
I'm trying to figure out the easiest way to send SQL Server Event Notifications to a separate server using service broker. I've built an endpoint on each server, a queue on each server, working on Dialogs and Contracts and activation... but do I need any of that?
CREATE EVENT NOTIFICATION says it can send the notification XML to a "target service" - so could I just create a contract on the "sending" server that points to a queue on a "receiving server", and use activation there?
Or do I need to have it send to a local queue and then forward on to the receiving server's queue? Thanks!
You can target the remote service, but you have to have the ROUTEs defined for bidirectional communication so that you get the Acknowledgement message back. I once had a script for creating a centralized processing server for all Event Notifications, and the other servers targeted it's service. If I can find it I'll post it on my blog and update this with a link.
I am researching SQL Server 2008 Service Broker. I want to get data from a web service and insert it into a queue. I understand sending messages from one queue to another, but how do I get the data into the first queue, in the first place?
When you SEND a message, its goes directly to transmission queue and from transmission queue to target services queue.
If you want to keep message for the lifetime of conversation, then you can ALTER QUEUE and use RETENTION = ON. In this case, message will be deleted from sender queue, when conversation ends.
I have a Sql Server inside a restricted network. I need to somehow get data from the outside in.
I would like to harness the use of Message Broker. My thinking is the external db places a message on a queue then I require a service that sits inside of the restricted LAN to listen (poll?) for these messages and then act upon them.
I cannot have the external queue initiate the normal broker conversation into the restricted LAN.
My question is should I be looking at the broker external activator to sit inside the restricted LAN and listen for new messages and then act upon them? Has anyone got any experience with this. Documentation / examples for external activator are pretty thin on the ground and monologues are not supported in message broker yet.
Is msmq a better option?
My recommendation would be to allow Service Broker to deliver the message all the way into the SQL Server instance inside the restricted lan. That will require the restricted LAN to allow incomming connection (allow the inside server to listen and accept). MSMQ would be no different, the MSMQ port(s) would have to be open in the restricted LAN.
If you want to use a dedicated process inside the restricted LAN that 'gets' the data inside then you must ensure the transactional consistency between the external server 'get' and the internal server write: the two operation have to be enrolled into a distributed transaction and the DTC protocol itself needs to be allowed to penetrate into the restricted LAN. So some ports still need to be open in the restricted LAN.
What your LAN security designers need to understand is that Service Broker connections are not Transact-SQL connections. Service Broker uses a dedicated protocol that only allows exchange of Service Broker messages. All traffic is encrypted and secured with RC4 or AES encryption. SSB cryptography is FIPS compliant. Allowing for Service Broker traffic to the SQL Server inside is probably the most secure way of allowing data from the external server to reach the secured server. In Service Broker networking there is no concept of 'client' and 'server' and one cannot design the network allowing connections only in one dirrection (eg. unlike say HTTP, which can be designed to connect from inside to outside but not the other way). SSB networking requires both machines involved to be able to connect to each other, because response messages can come after long delays (hours, days, consider the case when a queue is backed up so it takes a long time until the message is processed and a response is sent). IS not feasable to keep connecitons open for days to expect a response, so the receiver of a message must be able to connect back to the sender to deliver a response.