Geek Answers Handbook

Running PHP from ActiveMQ

Background: Our current system includes two services (one written in Java, the other in PHP) that communicate with each other using HTTP callbacks. We want to move from HTTP callbacks to a message-based architecture using ActiveMQ (or, if necessary, another). We will probably use STOMP to communicate between them. In the end, the PHP service will be rewritten in Java, but this is not part of this project.

Question: How does the ActiveMQ system notify PHP that a new message has been sent to the queue that the PHP system subscribes to? On the current system, the callback basically calls PHP and runs it. This goes away with message-based architecture.

Possible solutions:

  • Cron regularly calls a PHP script that checks for new messages. Ugh.
  • A long-term PHP process that loops around and sleeps and checks for new messages. less yuck?
  • ActiveMQ calls a PHP script when sending a new message. good as?
  • ??
+6
java php activemq message-queue stomp
source share
4 answers

Check out Camel . It can work inside ActiveMQ or on its own. Camel creates "routes" for messages. In this case, I would suggest that you leave the PHP callback URL as it is, and configure the route in Camel, which receives messages from the queue and sends them to the callback URL. You can then use Stomp in PHP to send messages to ActiveMQ. Your Java code can use JMS only for incoming and outgoing messages.

+4
source share

Do you have ActiveMQ to execute shell commands? If so, just run the ActiveMQ PHP script through the command line whenever there is a new message to process. This eliminates the need for cron jobs and a long PHP loop.

0
source share

Question: How can the ActiveMQ system notify PHP that a new message has been sent to the queue that the PHP system subscribes to? On the current system, the callback basically calls PHP and runs it. This goes away with message-based architecture.

I think you are working in the wrong direction. Consumers periodically check the queue for new messages, and not vice versa. If the queue is to notify the user about reading from it, then you really have not separated these applications, as you think.

0
source share

I think the problem they are trying to solve is that the LAMP stack (of which PHP is part) is inherently connected with the request / response mechanism that the HTTP protocol imposes on it, so it has a consumer (which checks ActiveMQ ), written in PHP, is workable, but the lifetime of processes is naturally limited by any timeout in the HTTP protocol. The solution is one of:

1 - Do not run the PHP Subscriber inside apache / HTTP, and as a result, you can set_time_limit (0) and run php Subscriber forever (until it works), OR

2 - Understand that the Subscriber actually performs "periodic" checks, while nothing happens between them, so instead of while (1) {do_queue_stuff (); sleep(); } you delete the sleep mode, delete the while loop, and call it again from Cron or similar.

Each has its own advantages, but both are equally good IF the cron () frequency is fine tuned. My Cron is limited to running every minute, which is not very common, so I would have to make a combination of the following two: it is called from cron every minute:

time = what_minute_is_it (); while (what_minute_is_it () == time) {do_queue_stuff (); sleep (1); }

I think that people can follow the ActiveMQ system "hinting" at the PHP Consumer system that there may be things in the queue that need processing, and, as a result, save all these processing queues / stop / sleep / etc. if there’s really nothing to do. A camel seems to be a way to do this.

0
source share

More articles:


All Articles