0

I have an executable that needs to process records in the database when the command arrives to do so. Right now, I am issuing commands via TCP exchange but I don't really like it cause a) queue is not persistent between sessions b) TCP port might get locked

The idea I have is to create a folder and place files in it whose names match the commands I want to issue

Like:

1.23045.-1.1
2.999.-1.1

Then, after the command has been processed, the file will be deleted or moved to Errors folder.

Is this viable or are there some unavoidable problems with this approach?

P.S. The process will be used on Linux system, so Antivirus problems are out of the question.

Zeks
  • 2,265
  • 20
  • 32

1 Answers1

1

Yes, a few.

First, there are all the problems associated with using a filesystem. Antivirus programs are one (though I cannot see why it doesn't apply to Linux - no delete locks?). Disk space, file and directory count maximums are others. Then, open file limits and permissions...

Second, race conditions. If there are multiple consumers, more than one of them might see and start processing the command before the first one has [re]moved it.

There are also the issues of converting commands to filenames and vice versa, and coming up with different names for a single command that needs to be issued multiple times. (Though these are programming issues, not design ones; they'll merely annoy.)

None of these may apply or be of great concern to you, in which case I say: Go ahead and do it. See what we've missed that Real Life will come up with.

I probably would use an MQ server for anything approaching "serious", though.

aib
  • 45,516
  • 10
  • 73
  • 79
  • Message queue server... hmmmm... that's certainly an idea. Thanks, I'll look into it. Truth be told - I have no experience with this kind of programming :) – Zeks Sep 02 '12 at 16:02
  • Theoretically, yes. Any particular server you have in mind? I will need to interact with it via c++. – Zeks Sep 02 '12 at 16:14
  • I had a "theoretically" at the beginning of that comment (and a rant about the word's implications at the end), but deleted them before posting :). I've only ever tried ActiveMQ and RabbitMQ, used Rabbit on two production systems, my decision based on what I read on the net at the time, and only with PHP and Java clients. I would probably go with whichever has the easiest-to-use and the most stable-looking client library. (If all else fails, Rabbit has an HTTP REST interface.) – aib Sep 02 '12 at 16:34
  • Note that even your database may have some queue support, or means of turning a table into one. – aib Sep 02 '12 at 16:46
  • It has but I need interactive response and that is the problem. I am literally bound to calling external c++ code from DB that issues a command and waits for response to return back. – Zeks Sep 02 '12 at 19:25
  • For now, I decided to try boost::interprocess::message_queue :) – Zeks Sep 02 '12 at 22:11
  • Ah, good choice. An MQ is an MQ. Sorry for not suggesting it, thinking too much about scalability must've poisoned me :) – aib Sep 02 '12 at 22:37
  • Actually, I already kinda got it working :) (with some help from google and a LOT of swearing) – Zeks Sep 03 '12 at 00:31
  • Ah, curse-driven programming. I'm *very* experienced in that. – aib Sep 03 '12 at 17:11