2016-07-19 11 views
0

испытания кластера из двух брокеров, схемы членства WKA, PostgreSQL хранилища сообщений, работает нормально в течение нескольких дней, а затем бросали следующие ошибки:WSO2 MB Cluster Давать сброс соединения по сверстников

TID: [] [] [2016-07-19 12:09:24,738] ERROR {org.wso2.andes.server.protocol.MultiVersionProtocolEngine} - Error establishing session {org.wso2.andes.server.protocol.MultiVersionProtocolEngine} 
java.io.IOException: Connection reset by peer 
    at sun.nio.ch.FileDispatcherImpl.read0(Native Method) 
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) 
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) 
    at sun.nio.ch.IOUtil.read(IOUtil.java:197) 
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) 
    at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:218) 
    at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:198) 
    at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400(SocketIoProcessor.java:45) 
    at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:485) 
    at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) 
    at java.lang.Thread.run(Thread.java:745) 

Ввод в Message Broker выглядит отлично, никаких ошибок, соединение JDBC с PostgreSQL DB в порядке, монтирование реестра выглядит нормально. Затем после этого появляется ошибка в wso2carbon.log несколько раз/мин. Любые идеи? Насколько я знаю, ничего не изменилось, и я не знаю, к чему он пытается подключиться.

+0

WSO2 MB 3.1 кластер. – TanyaK

+0

Здравствуйте, TanyaK, вы можете объяснить, что происходит с этим кластером MB. Вы используете очереди или темы. Это происходит в ходе длительного теста? Что такое TPS? –

ответ

0

Обычно это происходит, когда клиент, подключенный к МБ, пытается создать соединения для каждого сообщения. jms - это тяжелое соединение и не рекомендуется создавать соединения для каждого сообщения. Поэтому пройдите проверку клиента и убедитесь, что соединения не созданы для каждого сообщения.

Если случайно вы используете WSO2 ESB для публикации/подписки очереди/темы М.Б. есть свойство «transport.jms.CacheLevel» connection caching в ESB axis2.xml.Read documentation и использовать соответствующий уровень кэширования для вашего UseCase.

В связи с этим свойство кеширования должно быть проигнорировано в esb 4.8.1, которое также установлено в 4.9.0. Это возможные случаи, о которых я могу думать с данной информацией. Если вам нужна дополнительная информация, пожалуйста, предоставьте подробную информацию об использовании.