У нас невероятно неприятная ситуация с API на основе веб-сервисов CF, который мы написали и поддерживаем. В течение многих лет у нас был API, который был стабильным и успешно работал с клиентами Ruby, PHP и ColdFusion. Затем в этом году появился клиент .NET, и мы обнаружили, что наш веб-сервис не может взаимодействовать со статически типизированными языками из-за широкого использования структур.
В конце концов мы поняли, что пришлось переписать API без структур, и мы сделали это. Теперь он использует значения скейлера, массивы и CFC (которые переводятся в SOAP complexTypes). Клиент .NET доволен, и мы написали проверенные клиенты на 6 разных языках, чтобы обеспечить совместимость на этот раз.
К нашему великому сожалению, кажется, что наши серверы ColdFusion 7 не могут надежно обслуживать новый API. После перезапуска работает примерно день или около того, потом клиенты начинают получать ошибки вроде:
Ошибка: coldfusion.xml.rpc.CFCInvocationException
[java.lang.ClassNotFoundException: tafkan.remote_api.pfapi.v.trunk.rsp_pf_survey_status_array]
и
java.lang.NoClassDefFoundError: tafkan / remote_api / pfapi / v / trunk / pf_unit
Перезапуск экземпляров CF - единственный способ устранить проблему. Много времени и денег было потрачено на перестройку API, так что все действительно в этом уверены.
Мы заметили, что каталоги WEB-INF / cfc-skeletons наших экземпляров CF в конечном итоге, похоже, содержат две копии классов для каждого из CFC, используемых API. Например:
-rw-r--r-- Feb 17 09:15 remote_api.pfapi.v.trunk.pf_datum.class
-rw-r--r-- Feb 3 12:20 tafkan.remote_api.pfapi.v.trunk.pf_datum.class
Похоже, что ошибки происходят из-за проблем с пространством имен или путем поиска классов, поэтому мы попытались переключить все ссылки на CFC на полностью квалифицированные (точечная запись, начинающаяся с отображения) вместо простых ссылок на CFC в текущем каталоге. , Это казалось многообещающим, но проблема вернулась в течение 24 часов.
Окружающая среда:
- ColdFusion 7,0,2,142559 с hf702-70523, кластер из 2 экземпляров
- Sun Java 1.4.2_13
- Apache 2.0.52
- Centos 4.5 32-бит
Может быть, обновление одного из этих почтенных кусков программного обеспечения поможет? Может быть, обновление только ОСь?
Поддержка Adobe, похоже, не подходит, поскольку CF7 поддерживается EOL и имеет расширенную расширенную поддержку (и это только на несколько дней).
Обновление:
Спасибо всем, кто присоединился к этой дискуссии! Вот обновленная информация о том, как обстоят дела в данный момент.
Служба только что вышла сегодня впервые. Один из экземпляров кластера все еще мог генерировать WSDL, в то время как другой экземпляр сказал:
AXIS error
Sorry, something seems to have gone wrong... here are the details:
Exception - java.lang.NoClassDefFoundError: tafkan/remote_api/pfapi/v/trunk/rsp_pf_numeric_array
Обе директории cfc-skeletons содержат файл с именем tafkan.remote_api.pfapi.v.trunk.rsp_pf_numeric_array.class и не содержат файлов с другими именами, которые мы иногда видели (remote_api.pfapi.v.trunk .rsp_pf_numeric_array.class). Файлы в cfc-остовах, по-видимому, не были изменены с момента запуска серверов вчера.
Время безотказной работы в обоих случаях составляло около 21,5 часов. Я работал без JIT (-Xint).
Я перезапустил оба экземпляра. Теперь они работают на Sun Java 1.4.2_19 (вместо _13), и JIT был повторно включен, поскольку он явно не вызывал эту ошибку, а без нее все было значительно медленнее. Я также снял флажки «сохранять файлы классов».
А теперь мы снова ждем ...
Обновление 2
Проблема сохраняется. Я не уверен, что еще можно попробовать на этом этапе. Arg!
К вашему сведению, это кросс-пост в http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:60922