Я работаю над своего рода регистратором трассировки, который помещает запросы сообщений журнала в очередь на служебной шине, чтобы впоследствии их выбрала рабочая роль, которая вставила бы их в хранилище таблиц. Во время работы на моей машине это работает просто отлично (поскольку я использую его только один), но как только я установил его на сервере для тестирования, он выдал следующую ошибку:
HTTP_Request2_MessageException: Malformed response: in D:\home\site\wwwroot\vendor\pear-pear.php.net\HTTP_Request2\HTTP\Request2\Adapter\Socket.php on line 1013
0 HTTP_Request2_Response->__construct('', true, Object(Net_URL2)) D:\home\site\wwwroot\vendor\pear-pear.php.net\HTTP_Request2\HTTP\Request2\Adapter\Socket.php:1013
1 HTTP_Request2_Adapter_Socket->readResponse() D:\home\site\wwwroot\vendor\pear-pear.php.net\HTTP_Request2\HTTP\Request2\Adapter\Socket.php:139
2 HTTP_Request2_Adapter_Socket->sendRequest(Object(HTTP_Request2)) D:\home\site\wwwroot\vendor\pear-pear.php.net\HTTP_Request2\HTTP\Request2.php:939
3 HTTP_Request2->send() D:\home\site\wwwroot\vendor\microsoft\windowsazure\WindowsAzure\Common\Internal\Http\HttpClient.php:262
4 WindowsAzure\Common\Internal\Http\HttpClient->send(Array, Object(WindowsAzure\Common\Internal\Http\Url)) D:\home\site\wwwroot\vendor\microsoft\windowsazure\WindowsAzure\Common\Internal\RestProxy.php:141
5 WindowsAzure\Common\Internal\RestProxy->sendContext(Object(WindowsAzure\Common\Internal\Http\HttpCallContext)) D:\home\site\wwwroot\vendor\microsoft\windowsazure\WindowsAzure\Common\Internal\ServiceRestProxy.php:86
6 WindowsAzure\Common\Internal\ServiceRestProxy->sendContext(Object(WindowsAzure\Common\Internal\Http\HttpCallContext)) D:\home\site\wwwroot\vendor\microsoft\windowsazure\WindowsAzure\ServiceBus\ServiceBusRestProxy.php:139
7 WindowsAzure\ServiceBus\ServiceBusRestProxy->sendMessage('<queuename>/mes…', Object(WindowsAzure\ServiceBus\Models\BrokeredMessage)) D:\home\site\wwwroot\vendor\microsoft\windowsazure\WindowsAzure\ServiceBus\ServiceBusRestProxy.php:155
⋮
Я видел предыдущие посты, которые описывают похожие проблемы; А именно:
Это означает, что это известная проблема, связанная с библиотеками хранилища PHP Azure, где разрешено ограниченное количество соединений HTTPS. До того, как требования были изменены, я обращался к хранилищу таблиц напрямую, столкнулся с той же проблемой и исправил ее так, как описано в первой ссылке.
Проблема заключается в том, что конечная точка служебной шины в строке подключения, в отличие от конечных точек строки подключения Table Store (и т. Д.), ДОЛЖНА быть «HTTPS». Попытка использовать его с «HTTP» вернет ошибку 400 — Bad Request.
Мне было интересно, есть ли у кого-нибудь идеи о возможном обходном пути. Любой совет будет принята с благодарностью.
Спасибо!
РЕДАКТИРОВАТЬ (После комментария Гэри Лю):
Вот код, который я использую для добавления элементов в очередь:
private function logToAzureSB($source, $msg, $severity, $machine)
{
// Gather all relevant information
$msgInfo = array(
"Severity" => $severity,
"Message" => $msg,
"Machine" => $machine,
"Source" => $source
);
// Encode it to a JSON string, and add it to a Brokered message.
$encoded = json_encode($msgInfo);
$message = new BrokeredMessage($encoded);
$message->setContentType("application/json");
// Attempt to push the message onto the Queue
try
{
$this->sbRestProxy->sendQueueMessage($this->azureQueueName, $message);
}
catch(ServiceException $e)
{
throw new \DatabaseException($e->getMessage, $e->getCode, $e->getPrevious);
}
}
Вот, $this->sbRestProxy
REST-прокси служебной шины, устанавливается при инициализации класса ведения журнала.
В конце концов, вот код со стороны рабочей роли этого:
public override void Run()
{
// Initiates the message pump and callback is invoked for each message that is received, calling close on the client will stop the pump.
Client.OnMessage((receivedMessage) =>
{
try
{
// Pull the Message from the recieved object.
Stream stream = receivedMessage.GetBody<Stream>();
StreamReader reader = new StreamReader(stream);
string message = reader.ReadToEnd();
LoggingMessage mMsg = JsonConvert.DeserializeObject<LoggingMessage>(message);
// Create an entry with the information given.
LogEntry entry = new LogEntry(mMsg);
// Set the Logger to the appropriate table store, and insert the entry into the table.
Logger.InsertIntoLog(entry, mMsg.Service);
}
catch
{
// Handle any message processing specific exceptions here
}
});
CompletedEvent.WaitOne();
}
Где Logging Message — это простой объект, который в основном содержит те же поля, что и Сообщение, зарегистрированное в PHP (используется для десериализации JSON), LogEntry — это TableEntity, который также содержит эти поля, а Logger — это экземпляр Logger Table Store, настроенный во время метода OnStart рабочей роли.
Это была известная проблема с Windows Azure PHP, которая давно не рассматривалась и не была исправлена. В промежутке между тем, когда я это опубликовал, и сейчас, мы закончили писать отдельный веб-сервис API для ведения журнала, и наш PHP-код отправлял ему строки JSON через cURL, что достаточно хорошо работает как временное решение. Мы переходим от PHP сейчас, так что в любом случае это не будет проблемой гораздо дольше.
Других решений пока нет …