最近在協助處理一個PHP搭配 ActiveMQ 的系統問題，處理過程中習慣性的把所有可能的潛在原因都看一遍。又看到一些以前沒注意過的事情。就稍微記錄一下～ 找問題，自然是先打開log、觀察log中是否有任何的異常。觀察下來，發現偶爾會出現"Unexpected EOF while reading from socket"的錯誤。原以為這樣的錯誤訊息，是出現在 Stomp::readFrame 。沒想到，最後確認是發生於 Stomp::__construct ，程式開啟 ActiveMQ 連線時… 這樣的錯誤、與發生位置，相關性真令人百思不得其解。但無意間，在另一台主機測試時找到了答案～ 在測試連線時，將一樣的程式放到另一台主機上執行、測試時，故意給予錯誤的連線設定。測試結果卻是收到"Unable to connect to 127.0.0.1:61613"的錯誤訊息，和剛剛的不同。 最後找到原因，是因為兩台主機的 PECL :: Package :: stomp 版本不同，整理如下…

最近使用 redis 的 Lists 資料結構做些東西，採用 Reliable queue 這Pattern。 我開發環境的語言是PHP，連接 redis 的套件，採用 phpredis/phpredis: A PHP extension for Redis 這套。 雛形很快的就開發好了，沒想到，一測試就遇到以下的錯誤…程式無法達到預期-持續的連接於redis接收 Lists 內的資料。 RedisException: read error on connection in XXXXX.php 由於我是使用 brpoplpush 這指令操作，不經懷疑blocking的操作方式會受redis.conf中的timeout參數的影響。當初，考量redis的運作方式，因此刻意調整此參數避免redis被單一client卡住。畢竟設定檔中的timeout參數是這樣說明的…

不要錢的最貴，最近又遇到一個案例…這次的狀況是，安裝一台新主機，把一些程式搬移到這台新主機。結果，一個連ActiveMQ的程式出了問題。當下看到的狀況是，producer可以將資料送到ActiveMQ，但是資料卻是空白，導致customer無法處理。後續的問題釐清中，確定只有在新主機的producer才會發生此問題，原主機無問題。 新主機上安裝的 pecl-stomp 是1.0.5，舊主機為 pecl-stomp 1.0.3。原以為 pecl-stomp 是否有大改版造成此問題？但，查了change log卻又看不出有重大改變。 所幸，有位精通抓封包的同事比對了新舊主機，相同程式（producer）丟出封包的差異，發現有問題的新主機再丟資料給ActiveMQ時，多了如下的header content-length:15 查了 ActiveMQ-Stomp ，瞭解到content-length對ActiveMQ有特殊的含意。節錄如下…

在測試ActiveMQ過程中，發現發生下面狀況時，ActiveMQ可能就會出現異常的狀況 當queue內累積過多的筆數 當queue內累積太多的資料內容 要多少筆數？多少資料量？才可能出現異常呢？官方資料中，沒有找到明確的數據。 根據測試的經驗，這個數字依舊和機器等級有差。當procedure往queue塞資料的速度大於consumer消化速度，讓queue內的資料筆數一直累積上去。會導致consumer處理速度越來越慢、惡性循環下去。其實，procedure的處理能力，也會越來越差。 如果queue繼續累積下去，會出現無法連到ActiveMQ。甚至WEB管理介面也失效、最後要重新啟動ActiveMQ。最慘的狀況是，當重新啟動後，還要將剛剛的queue刪除，才能恢復正常。 也曾遇過一個狀況，ActiveMQ的主機，最後因stock吃完而無法服務。 因此，需要監控ActiveMQ的狀況。或者，在procedure中檢查queue內的數量，作為後續處理的依據。（當然，還是要看怎麼規劃、運用ActiveMQ） 如何以PHP+STOMP取得ActiveMQ的資訊呢？

failover，在實務上的應用很重要。 Apache ActiveMQ Failover Transport Reference 中有說明。關於stomp failover作法，程式很簡單如下…詳細說明請見 stomp文件-Failover 。 $link  =  new  Stomp( "failover://(tcp://192.168.1.1:61613,tcp://192.168.1.2,:61613)?randomize=false" )   上述php code，我以 pecl-stomp 測試，卻會出現如下錯誤訊息 StompException , Invalid Broker URI scheme 參考 Apache ActiveMQ ™ -- Failover Transport Reference 的Configuration Syntax，改用其他的URI寫法，依舊會有錯誤…

上次在 php使用stomp操作ActiveMQ 提到，PHP採用預設值去連ActiveMQ，處理速度異常緩慢。解決之道，可以藉由更改activemq.prefetchSize的值而得到改善。不過…改變activemq.prefetchSize會不會有什麼問題？或影響？ 首先，需要先提到redelivery這個名詞。可以先參考官方文件 Message Redelivery and DLQ Handling 在不修改預設值的情況下，當PHP（customer）使用STOMP和ActiveMQ取得一筆message後，該message id就會被標為redelivery（Redelivered=TRUE）。直到customer回覆ack（acknowledge）後，該message會轉成Messages Dequeued。如果customer沒有回覆ack呢？customer將會無法取得下一筆message…PHP（customer）就卡在哪了… 當我們修改activemq.prefetchSize後，會改變上述的行為模式。做個實驗…

最近終於可以抽了點時間試一下php和 ActiveMQ 這樣的組合。遇到了些狀況，在大家解決這些狀況的過程中，挖到更多的相關資訊。所以，做個記錄… 這次的測試，覺得ActiveMQ和JAVA比較親，其他的語言大部分須要靠STOMP（全名為Simple (or Streaming) Text Orientated Messaging Protocol。）然而，有些功能在STOMP上並沒有實做、或者處理方式不太相同。 既然是php和 ActiveMQ 的組合，就必須先瞭解一下STOMP。寫這記錄時，一般使用的STOMP都是 STOMP 1.0 。以php所提供的extension stomp pecl來說，它文件中雖然沒提到所採用的版本，但以它目前最新的版本-Release 1.0.3來說，是在2010所出。當時還沒出 STOMP Protocol Specification, Version 1.1 （官網提到1.1 Released on 2011/3/31）。推算時間，應該是採用 STOMP 1.0 寫這記錄時，官網文件 - stomp Implementations 提到，目前支援 STOMP 1.1 的僅 Apache Apollo 。文件中是對 Apache Apollo 的描述如下…感覺上對STOMP的支援程度似乎比較好？ Apache Apollo a redesigned version of ActiveMQ focused on STOMP messaging. 在 Apache Apollo 官網上，是如此描述自身產品 ActiveMQ Apollo is a faster, more reliable, easier to maintain messaging broker built from the foundations of the original ActiveMQ. It accomplishes this using a radically different threading and message dispatching architecture. 至今，居然只有支援STOMP。之後才會加上其他的protocol。感覺… Apache Apollo 似乎沒有獨厚JAVA…不過，沒實際測過，就不下結論… ...