tags:

views:

88

answers:

2

What is the best way for a server to process messages in Perl?

I'm trying

while ( 1 ) {
  # Get Queue Messages
  # Do Work
  sleep( 10 );
}

My mysql schema is of the sort

create table message (
  id int auto_increment primary key,
  processed int,
  message varchar(100)
)

and in my "#Get Queue Messages", I do a request like

select * from message where processed = 0

and then flip the flag when it's done.

Is there a better way to do this?

+1  A: 

Well, it depends on what these 'messages' are and how far you want to go. For a lot of circumstances, what you're doing is probably just fine.

If you're using this mechanism for a high volume of interprocess communication traffic between your server and its clients, though, you may be committing an instance of the 'database-as-IPC anti-pattern'. What's basically meant by that is that it's not a good thing to use a database for routine, high-volume message passing between processes.

If this message table is being used that way, you might want to look into doing a 'proper' IPC implementation. The Perl IPC man page has plenty of useful information for this.

chaos
They're mostly requests from apache/web, which I'm trying to offload to a daemon.I also intend to keep all these messages though, will this scale?
Timmy
It won't scale very well to large numbers of messages, no. Whether it's workable depends on how many messages you're actually going to process. It's probably a good idea to do monthly message tables instead of a single one, or even daily if this is going to be a real high-volume application. Or, of course, you could use non-database IPC mechanisms like I refer to, for telling the daemon directly what you want to have processed. If you want/need a permanent record of the messages, though, then pushing them into a database is appropriate.
chaos
+1  A: 

It sounds to me like what you really want is a job queue, like Gearman or TheSchwartz.

trendels