Posts

Showing posts with the label RabbitMQ

A tryst with message queues Pt. 4

So far... I have installed RabbitMQ server on my development machine and using it to test my development code. I have STOMP_SEND working fine. Using the management web console for RabbitMQ I can see the messages being queued. Now I have to read the sent messages. And here I stumbled into a situation where libstomp's stomp_read function was failing. So now going ahead, I integrated the message sending code into the product. The requirement was simple. We had to send a fixed message to a queue with time stamp every two mins. So I put together a thread and put the message sending logic into it. After testing it, I started work on the read part. The requirement was simple. The product has to read some messages from a queue and display them to user. Thankfully one of the system guys fixed libstomp ( saving me some efforts :D ), and made the stomp_read working again. So after putting together a test application to read from the queue, I ended up with a no of problems. First o...

A tryst with Message Queues Pt. 3

So once I have called it quits on the R&D, I started work on the integration thing. The problem has grown tenfold by now. The powers that be want to do a lot of messaging stuff and its become a list of at least half a dozen changes where messages are to be introduced. Now, there's another angle. I am serving notice period, the recruitment people are having hard time finding a replacement and its my last three weeks here. I should be doing the handover. Shouldn't be working on these new features - especially things as complex and less understood as this STOMP stuff. But what can you do when the powers that be want to push in code without worrying about the future of that code. So I sat silently on this wet and cold Monday morning, trying to figure out the integration strategy. Yeah, the code is all C code, so better to keep it all together. Means a single function which connects to server, sends the message and disconnects. What can I pass? We need to fetch in settings f...

A tryst with Message Queues Pt. 2

So far... I'm sending data to a RabbitMQ broker as messages. These messages get queued up in a user configurable queue. Supposedly a consumer is going to process these. But the consumer is out of my view. Doesn't matter. Now there came a feature of receiving notifications from the consumer or some other system. So after some discussion, the powers to be decided that we are going to have a notification queue which the client has to read. And from it we get the notifications to be read. Now the shady part of business was I had no idea what the hell is going on the inside of libStomp. So I ask politely that I don't have any read code. And I get handed over a single stomp_read code snippet. (In whiny voice) They said it works!!! But it doesn't!!! I tried so hard!!! Damn!!! So I looked into the protocol to understand why the hell I am no getting anything. After reading the protocol, I came to know that the implementation is fucked up in ways more than a few. First ...

A tryst with Message Queues Pt. 1

I need to give some background for this situation. Its like this: we have a client server product. The server is written in .net and performs analysis on raw data collected from a number of clients and prepares various reports. The client software is written in c++/Qt and it interacts with various hardware controllers/ sensors to get the raw data. There is a sync program written in .net that runs on the server and it pulls data from all the clients. The data is saved in servers PostgreSQL database for later processing. Now, the powers to be decided that we need to remove this syncing program ( because it sunk the data into oblivion sometimes! :D ). So what's the replacement? Well, they decided on RabbitMQ as the queuing solution and decided that the clients would sync their own data to the queue and from there it will be fetched by the server. So we as clients needed to have this functionality in our application. But after looking at the complexity of our own client, we...