Jump to content

Queue implementation in php


kbird

Recommended Posts

hi guys,

 

I want to implement a queue process system. I am hoping for some queue process such as you find 'ActiveMQ' for java. I have an application that built on ZendFramework which is called Magento.

 

Can some one suggest me how you can implement a queue process in PHP applications, please share your thoughts

 

Thanks.

 

Link to comment
Share on other sites

Please explain what you mean by queue process system as there are many ways to implement a queue system.

 

thanks a lot ignace. This is what i want to do. i am have module (in application) which has to keep sending some xml request to some external system, external system send me back responses based on xml requests. these xml requests are passed frequently.

 

now i want to put these xml requests in queue system where a component will pick up the xml requests from it start send and receiving the xml.

 

I was looking for some sort of message queuing system such as you find like what 'ActiveMQ' does. Any suggestions?

 

 

Link to comment
Share on other sites

There is a whole series of application servers that provide queing of requests, so if you have a high transaction environment you can build an asynchronous application that is highly fault tolerant and able to adapt to changes in transaction volume.  One example might be a logging application, where a client event occurs and you want to queue that data and then go on with processing.  So the client enqueues the data and goes on its merry way with no code to handle logging.  A seperate logging application dequeues the messages from the queue and writes out the log entry.  This type of architecture is often used with distributed architectures, where you have multiple clients enqueing messages, and multiple servers dequeuing.

 

Oracle Advanced Queue is one such implementation that is a great feature for Oracle shops, and can be used in a lot of different ways.  ActiveMQ is a queue server written in Java.  Last year I worked on a project where we wanted a queue server.  I looked at and tried a few different things.  Starling is a ruby app that was/is used at Twitter.  They open sourced a version of it, but it seems basically to be a dead project.  I tested it and it was not stable under the OS we were using it with (Centos).

 

Ultimately I used memcacheq.  We had reasons to want to interface with the queue using the memcache protocol since we were also using memcache in the application, and memcacheq has the advantage of looking to php like a memcache server, even though it is actually backed by BDB storage.

 

I also looked hard at Q4M which really appealed to me since it is similar to what I was used to with Oracle AQ.  Q4M basically was unusable by us at the time because it required a version of Mysql we couldn't use.  The project has progressed since then and I'd certainly consider it since you could enque messages using the mysql client libraries that are already available, since Q4M would look to php like a mysql database.  There are still some rough edges, but I would certainly evaluate it now.  http://q4m.31tools.com/

 

Last but not least, PHP can interface with ActiveMQ using the STOMP library.  There is plenty of documentation about doing this.

 

You could of course implement your own queue server in a variety of ways.  A typical ajax or REST interface would work fine -- store messages in a mysql database, and all you would need to sort out is the API.  Of course the efficiency and fault tolerance of doing this is kind of lost if this is just a bunch of processes running on the same server, and designing the application around a queuing system doesn't really make sense.

Link to comment
Share on other sites

Thanks a lot gizmola. supprised to hear php can interface with ActiveMQ. I am going to check that out!

 

There is a whole series of application servers that provide queing of requests, so if you have a high transaction environment you can build an asynchronous application that is highly fault tolerant and able to adapt to changes in transaction volume.  One example might be a logging application, where a client event occurs and you want to queue that data and then go on with processing.  So the client enqueues the data and goes on its merry way with no code to handle logging.  A seperate logging application dequeues the messages from the queue and writes out the log entry.  This type of architecture is often used with distributed architectures, where you have multiple clients enqueing messages, and multiple servers dequeuing.

 

Oracle Advanced Queue is one such implementation that is a great feature for Oracle shops, and can be used in a lot of different ways.  ActiveMQ is a queue server written in Java.  Last year I worked on a project where we wanted a queue server.  I looked at and tried a few different things.  Starling is a ruby app that was/is used at Twitter.  They open sourced a version of it, but it seems basically to be a dead project.  I tested it and it was not stable under the OS we were using it with (Centos).

 

Ultimately I used memcacheq.  We had reasons to want to interface with the queue using the memcache protocol since we were also using memcache in the application, and memcacheq has the advantage of looking to php like a memcache server, even though it is actually backed by BDB storage.

 

I also looked hard at Q4M which really appealed to me since it is similar to what I was used to with Oracle AQ.  Q4M basically was unusable by us at the time because it required a version of Mysql we couldn't use.  The project has progressed since then and I'd certainly consider it since you could enque messages using the mysql client libraries that are already available, since Q4M would look to php like a mysql database.  There are still some rough edges, but I would certainly evaluate it now.  http://q4m.31tools.com/

 

Last but not least, PHP can interface with ActiveMQ using the STOMP library.  There is plenty of documentation about doing this.

 

You could of course implement your own queue server in a variety of ways.  A typical ajax or REST interface would work fine -- store messages in a mysql database, and all you would need to sort out is the API.  Of course the efficiency and fault tolerance of doing this is kind of lost if this is just a bunch of processes running on the same server, and designing the application around a queuing system doesn't really make sense.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.