Мои сообщения не доходят, но отправленные мне - я получаю. В Psi+ все работает

[GoogleCodeExporter]

What steps will reproduce the problem?
1. добавте аккаунт Facebook в основной профиль 
Vacuum IM по инструкции в разделе "Помощ" на 
странице Facebook.
2. Подключите аккаунт Facebook - статус on-line.
3. Отправьте сообщение одному из контактов 
в ростере аккаунта Facebook. Обязательно 
дождитесь подтверждения, что сообщение 
дошло - например используя чат на сайте 
Facebook.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
Я использую Vacuum IM 1.1.2 1680. OS - Windows 7x64 
максимальная.

What version of the Qt are you using?
Qt - 4.8.0

Please provide any additional information below.

Original issue reported on code.google.com by dr.kochu...@gmail.com on 22 Feb 2012 at 3:09

[GoogleCodeExporter]

Проверил, всё работает. Vacuum-IM 1.1.2, Qt 4.7.4, FreeBSD 9

Original comment by gelraen.ua on 27 Feb 2012 at 5:35

[GoogleCodeExporter]

Original comment by potapov.s.a on 27 Feb 2012 at 7:03

• Changed state: Checking
• Added labels: Type-Defect
• Removed labels: Type-Unknown

[GoogleCodeExporter]

Возникает такая же ситуация, смоделировать 
пока не удается, т.к. ошибка плавающая...
Сервер Openfire 3.6.4, Vacuum 1.2.0.1637.
Скорее всего приводит к этому такая 
последовательность действий.
1. Сервер Openfire работает.
2. С утра все клиенты Vacuum автозапуском 
соединяются c сервером.
3. Заходим на сервер останавливаем службу 
openfire.
4. Естественно клиенты отваливаются.
5. Через 5 минут запускаем службу.
6. Клиенты на автомате подключаются к 
серверу.
7. Далее, у некоторых клиентов возникает 
ситуация при которой их сообщения доходят 
до адресата, а они не видят сообщения, 
которые направляются в их адрес.
8. Пробовал открывать консоль у проблемного 
клиента (клиент1), в консоле видно как 
уходят блоки информирующие о том что 
клиент1 печатает сообщение для клиент2. 
Далее видно само сообщение от клиент1 к 
клиент2. Но если клиент2 отправляет 
сообщение к клиент1, то в консоле ничего не 
отображается.

Подскажите, кто тут виноват Openfire или Vacuum-IM ?

Original comment by koledas...@gmail.com on 6 Mar 2012 at 8:51

[GoogleCodeExporter]

Если в консоли ничего нет, значит виноват 
сервер, от него не пришло сообщение.

Original comment by potapov.s.a on 6 Mar 2012 at 11:05

[GoogleCodeExporter]

What steps will reproduce the problem?
Заново с нуля развернул сервер Openfire 3.7.1 и 
всех клиентов обновил до 1.2.0.1772.
На Openfire 3.7.1 стоит плагин Open Archive (т.е. история 
хранится на сервере)
Опять встречаются (причем очень часто) 
следующая проблема:
1. Есть 2 клиента клиент1(проблемный) и 
клиент2, у обоих запущен Vacuum и статус стоит 
"Доступен"
1. клиент1(проблемный) пишет сообщение 
клиенту2 - клиент2 получает сообщение 
(сообщение видно в консоле первого и 
второго).
2. клиент2 пишет сообщение клиенту1 - клиент1 
сообщение не видит (сообщение видно только 
в консоле второго).
3. на сервере Openfire видно что в разговоре 
сохранились оба сообщения.
4. на клиенте2 захожу в историю переписки с 
клиентом1 - история отображается, видно оба 
сообщения
5. на клиенте1 захожу в историю переписки с 
клиентом2 - история не подгружается, причем 
окно опрашивает данные дольше чем обычно 
(секунд 20)
6. на клиенте2 в ростере видно что клиент1 в 
сети (лампочка желтая)
7. на клиенте1 в ростере отображается что 
клиент2 не в сети (лампочка серая, хотя оба 
клиента в статусе "Доступен")
8. на клиенте2 в ростере щелкаю правой 
кнопкой по клиенту1 и выбираю "Версия 
приложения" окно висит потом пишет "Ошибка: 
Истекло время выполнения запроса".
9. Видно что на клиенте1 активность 
контактов в ростере отображается не 
корректно.

В общем складывается впечатление, что 
данные от клиента1 на сервер уходят, а с 
сервера он получить их не может. Если на 
клиенте1 изменить статус на "Отключен", а 
затем "Доступен" то проблемы исчезают. 
Причем в логах Openfire ошибок нету.
Народ уже матерится, а мне и сказать нечего 
:)

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
Vacuum-IM 1.2.0.1772
WinXP SP3
Openfire 3.7.1(с плагином Monitoring Service)

What version of the Qt are you using?
4.7.4

Please provide any additional information below.

Original comment by koledas...@gmail.com on 20 Mar 2012 at 6:57

[GoogleCodeExporter]

Странно все это, единственное что можно 
попробовать, это посмотреть действительно 
ли до клиента1 не доходят данные 
каким-нибудь снифером. Если данных 
действительно нет то нужно смотреть на 
сервер. Пришли еще лог подключения на 
проблемном клиенте.

Original comment by potapov.s.a on 20 Mar 2012 at 7:04

[GoogleCodeExporter]

Хм, что за лог подключения? где его взять?

Original comment by koledas...@gmail.com on 20 Mar 2012 at 7:10

[GoogleCodeExporter]

В XML консоли, открываешь её и подключаешься

Original comment by potapov.s.a on 20 Mar 2012 at 7:15

[GoogleCodeExporter]

Если я переподключусь, то проблемы 
исчезнут и в консоле скорее всего всё будет 
в порядке. Проблема плавающая. Попытаюсь, 
может получится, поймать.

Original comment by koledas...@gmail.com on 20 Mar 2012 at 7:18

[GoogleCodeExporter]

Вроде получилось словить ошибку. Лог 
прилагаю.
Сделал так:
1. Открыл консоль на 3-х клиентах
2. Перезапустил службу Openfire
3. Все клиенты отрубились и начали 
автоматом подключаться
4. Все трое перешли в состояние "Доступен", и 
все три оказались проблемными, ни от кого 
из них не удаётся получить версию 
нормального клиента.

Original comment by koledas...@gmail.com on 20 Mar 2012 at 7:32

Attachments:

• logs_vacuum.zip

[GoogleCodeExporter]

Вроде все нормально, попробуй седлать 
фиксированные ресурсы, это единственное 
что приходит в голову.

Original comment by potapov.s.a on 20 Mar 2012 at 8:15

[GoogleCodeExporter]

Ок, но вначале посмотрю как завтра будет 
работать, завтра с утра все автоматом 
подключатся и посмотрю что будет. Есть 
подозрение что это глюки Openfire, что он не 
успевает до конца загрузиться(после 
перезапуска службы) и создает корявые 
подключения.
Спасибо за уделенное время!

Original comment by koledas...@gmail.com on 20 Mar 2012 at 8:30

[GoogleCodeExporter]

Т.е. проблема возникает только при 
перезапуске сервера?

Original comment by potapov.s.a on 20 Mar 2012 at 8:32

[GoogleCodeExporter]

Точно не знаю, просто новый сервер работает 
два дня и оба дня я перезагружал службу во 
время работы клиентов. Завтра с текущего 
момента до конца завтрашнего дня не буду 
перезагружать и посмотрим что будет.
А вобще перезапусками вакуума проблему не 
удалось смоделировать.

Original comment by koledas...@gmail.com on 20 Mar 2012 at 9:01

[GoogleCodeExporter]

В общем так, с утра все начали подключаться 
нормально, и я даже обрадовался что всё 
получилось. Но через какое-то время 
практически все клиенты стали гнать. Почти 
ни у кого из них не проверялась версия 
приложения. Решил продолжить издеваться 
над Openfire.
1. Первое что сделал - увеличил максимальное 
значение размера памяти Java до 1538Мб и 
рестартанул (не помогло, ни у одного не 
проверялась версия).
2. Пробовал поиграться с настройками Idle 
Connections Policy (не помогло, тоже само) - в итоге 
оставил чтоб не отключал клиентов при 
простое.
3. В итоге дошел до "Server Settings - Compression Settings" 
стояло "Available" - Отключил, рестартанул 
службу и вуаля - все клиенты 
переподцепились корректно и у всех стала 
проверяться версия.

Так вот теперь есть 2 пути проблемы:
либо гонит компрессия на стороне сервера, 
либо на стороне клиента.
Видел что в Issue 484 было упоминание про 
плагин compress. Может проблема в нём?
Нам в принципе компрессия не нужна, 
посмотрим как будет работать завтра...

Original comment by koledas...@gmail.com on 21 Mar 2012 at 5:36

[GoogleCodeExporter]

Хм, да это уже не в первый раз из-за сжатия 
появляются проблемы, но они уж очень 
какие-то избирательные, ведь раньше у вас 
такой проблемы не было, после чего она 
появилась?

Original comment by potapov.s.a on 21 Mar 2012 at 6:43

[GoogleCodeExporter]

Раньше стояла версия Openfire 3.6.4, проблемы 
также были, только реже
и в нём параметр xmpp.client.compression.policy=optional
Сейчас стоит версия 3.7.1
И проблемы ушли только после того как 
установил xmpp.client.compression.policy=disabled
Вобще лично я склоняюсь к тому что проблема 
в Openfire.
Но мало ли, вдруг в Vacuum можно подставить 
какой-то костыль...
С отключенным параметром на данный момент 
всё превосходно, пока никто не жаловался и 
на серваке логи чистинькие. Если так будет 
и дальше, то для нас проблема решена.

Original comment by koledas...@gmail.com on 21 Mar 2012 at 6:58

[GoogleCodeExporter]

Да и еще раньше использовалась версия 
вакуума 1.2.0.1637
а теперь 1.2.0.1772

Original comment by koledas...@gmail.com on 21 Mar 2012 at 7:00

[GoogleCodeExporter]

В r1783 сжатие потока сделано опциональным и 
отключенным по умолчанию.

Original comment by potapov.s.a on 25 Mar 2012 at 11:46

• Changed state: Fixed