Добавлено: Сб Фев 14, 2009 1:02 pm (спустя 9 дней 19 часов 34 минуты; написано за 1 минуту 12 секунд)
Заголовок сообщения:
В текущей бета-версии библиотеки есть проблема с чрезмерном расходованием CPU из-за busy wait. В ближайшее время будет фикс, который эту проблему решит. К сожалению, не все так просто в curl_multi...
По сему, имеет смысл пользоваться WS-Addressing =) Правда тут возникает проблема с синхронизацией, потому как спека предполагает, что запрашиваемый сервер будет пинать коллбэк на запрашивающем.
Добавлено: Вс Фев 22, 2009 1:15 am (спустя 7 дней 12 часов 6 минут; написано за 1 минуту 47 секунд)
Заголовок сообщения:
Busy wait я, кстати, уже починил. На днях выложу.
WS-Addressing, насколько я понимаю, не совсем про это. Dklab_SoapClient позволяет распараллеливать загрузку разных кусков страницы, синхронизируясь в конце для вывода самой страницы. А WS-Addressing, если не ошибаюсь, это способ асинхронного ПОЛУЧЕНИЯ сообщений, а не асинхронной отправки с последующей синхронизацией.
Зарегистрирован: 29.04.2003
Сообщ.: 4035 Карма: 253 поощрить/наказать
Откуда: Питер
Добавлено: Вс Фев 22, 2009 11:53 am (спустя 10 часов 38 минут; написано за 26 минут 51 секунду)
Заголовок сообщения:
WS-Addressing это просто техника для снижения нагрузки на железо за счёт минимизации времени жизни соединений. Например, если время работы удалённой системы может достигать десятков минут, логичным выходом будет отправить туда запрос и закрыть соединение. Удалённая система в определённый момент проснётся, и отдаст нам данные используя наш коллбэк сервис.
Ровно ту же схему удобно использовать и в случае необходимости получения данных от большого числа удалённых систем. Чаще всего все эти данные не являются уникальными для каждого запроса, в результате чего можно реализовать примерно такую схему работы: 1) Кеш данных 2) Кеш запросов 3) Набор клиентов для отправки запросов 4) Набор коллбэков 5) Синхронизационный тред, проще всего завязанный на семафоры (обычно с неким таймаутом), или некий кеш запросов
Если же данные уникальны, из схемы просто выкидывается кеш данных (1).
Как оно работает: 1) отправляются запросы с сохранением их ID в неком расшаренном кеше (напр. в том же memcached) 2) состояние кеша запросов опрашивается с неким интервалом, до истечения таймаута или получения всех ответов 3) коллбэк сервис при получении ответа обновляет инфу в а) кеше запросов б) в кеше данных 4) по окончании (2) заполняем все блоки данных свежими (или не очень, или не заполняем) данными
Такая организация немного сложнее нежели работа с асинхронными запросами, но имеет большое преимущество - кардинальное снижение нагрузки на железо за счёт 1) создания только одного синхронизационного треда, независимо от количества опрашиваемых сервисов 2) отсутствия необходимости в сохранении открытого канала к удалённому сервису
Дмитрий Кóтеров писал(а):
асинхронного ПОЛУЧЕНИЯ сообщений, а не асинхронной отправки с последующей синхронизацией
Ну, вопрос "последующей синхронизации" это просто вопрос о терминах. Оба варианта распараллеливают работу, другое дело что они этим занимаются на разных уровнях: 1) асинхронные запросы - на уровне исполняемого кода 2) ws-addressing - на уровне транспорта
PS: Мы как раз сейчас реализуем именно такую схему (правда в рамках axis2/java) на базе ws-addressing, поскольку затраты на установление "обратного" соединения ниже, нежели на создание большой кучи параллельных тредов. =) PPS: к PHP можно попробовать прикрутить axis2/C, который и реализует всякие радости вида ws-addressing, ws-policy и иже с ними.
Добавлено: Ср Фев 25, 2009 11:49 pm (спустя 3 дня 11 часов 55 минут; написано за 1 минуту 32 секунды)
Заголовок сообщения:
version 0.92: - Fixed bug with busy wait. CPU is now used efficiently. - Added $result->waitForConnect() method useful when you need to create a number of asynchronous requests and continue the main process execution while these requests are guaranteed begun their processings.
Добавлено: Ср Мар 31, 2010 1:30 pm (спустя 1 год 8 дней 12 часов 24 минуты; написано за 5 минут 16 секунд)
Заголовок сообщения: Проблема с Dklab_SoapClient
Здравствуйте,
У меня такая проблема. В WSDL mode всегда возвращается такой результат: SOAP response is empty. Если не-WSDL mode, то всегда возвращается такой результат: Unable to handle request without a valid action parameter. Please supply a valid soap action.
При этом если работать со стандартной SOAP библиотекой PHP, то всё работает.
[result] => 0 [result_timeout] => [body] => soap:ClientUnable to handle request without a valid action parameter. Please supply a valid soap action. [headers] => HTTP/1.1 500 Internal Server Error Date: Wed, 31 Mar 2010 10:20:19 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Cache-Control: private Content-Type: text/xml; charset=utf-8 Content-Length: 435 ) Exception: Unable to handle request without a valid action parameter. Please supply a valid soap action.
P.S. И ещё вопрос можно ли с помощью Dklab_SoapClient авторизоваться на soap серврере c помощью SSL сертификата (.pem)? В стандартной SOAP библиотеке это можно было сделать так: $client = new SoapClient("https://www.baltaonline.lv/Veseris/Policy/18.asmx?wsdl", array('local_cert' => 'mycert.pem'));
Добавлено: Ср Июл 28, 2010 6:10 pm (спустя 3 месяца 28 дней 4 часа 39 минут; написано за 1 минуту 20 секунд)
Заголовок сообщения: Проблема с Dklab_SoapClient
Вы не можете начинать темы. Вы можете отвечать на сообщения. Вы не можете редактировать свои сообщения. Вы не можете удалять свои сообщения. Вы не можете голосовать в опросах. Вы не можете прилагать файлы к сообщениям. Вы можете скачивать файлы.