amironov73 написал(а):
-------------------------------------------------------
> > Должен отметить, что многие версии клиентов
> > отправляют неверное с точки зрения Прокси
> значение
> > длинны запроса.
>
>
> Можно привести конкретные примеры: какие клиенты и
> что именно посылают (мало/много)?

Если можно, прокомментирую вопрос позже. Сейчас как раз с Константином Сбойчаковым его анализируем.


Я стокнулся с проблемой вывода сложной поисковой формы. Есть ли какие-то фиксированные ограничения по таймауту или размеру пакетов?

Кирилл Соколинский (СЗТУ) написал:
-------------------------------------------------------
> Я стокнулся с проблемой вывода сложной поисковой
> формы. Есть ли какие-то фиксированные ограничения
> по таймауту или размеру пакетов?

Ограничений по размеру пакетов в прокси я не закладывал.
Ограничения по таймауту, если не перенастраивать прокси (я полагаю, большинство пользователей так и поступают), берутся из операционной системы и, скорее всего, вполне разумны. Во всяком случае, при работе в локальной сети их вообще не должно быть заметно.

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

Будем думать, где может скрываться причина проблемы…

amironov73 написал(а):
-------------------------------------------------------
> Кирилл Соколинский (СЗТУ) написал:
> --------------------------------------------------
> -----
> > Я стокнулся с проблемой вывода сложной
> поисковой
> > формы. Есть ли какие-то фиксированные
> ограничения
> > по таймауту или размеру пакетов?
>
> Ограничений по размеру пакетов в прокси я не
> закладывал.
> Ограничения по таймауту, если не перенастраивать
> прокси (я полагаю, большинство пользователей так и
> поступают), берутся из операционной системы и,
> скорее всего, вполне разумны. Во всяком случае,
> при работе в локальной сети их вообще не должно
> быть заметно.

Интересно всё-таки, какие значения таймаута по дефолту. Очень хотелось бы их изменить.

> Если возможно, хотелось бы увидеть
> последовательность шагов, приводящую к сбою.

Я думаю, смоделировать ситуацию не сложно. Достаточно запустить любую форму на большой базе.

Засёк -- форма выполняется 2 минуты 10 секунд. При обычном режиме использования диалог сохранения возникает, при использовании через прокси через практически ровно 2 минуты результат -2222.

ОТладка ИРБИС-сервера показывает, что пакет ответа формируется. Размер формы небольшой -- 600 килобайт.


В протоколе:

------------------------------------------------------------
71) 14.02.2014 3:55:26 from 127.0.0.1:28352 at stage 9
Request 56 byte(s), response 0 byte(s), duration 0 ms
------------------------------------------------------------
Request header:
Command1: 7
Workstation: C
Command2: 7
UserID: 881908
Index: 4
Password: 2
Username: 2
------------------------------------------------------------
Request body:
IBIS
@BARCODE



0
0

0
0
0
------------------------------------------------------------
Response header:
Command:
UserID:
Index:
------------------------------------------------------------
Response body:



Редактировано 1 раз. Последний раз 14.02.2014 00:26 пользователем Кирилл Соколинский (СЗТУ).

Кирилл Соколинский (СЗТУ) написал:
-------------------------------------------------------
> ОТладка ИРБИС-сервера показывает, что пакет ответа
> формируется. Размер формы небольшой -- 600
> килобайт.
> В протоколе:
> --------------------------------------------------
> 71) 14.02.2014 3:55:26 from 127.0.0.1:28352 at
> stage 9
> Request 56 byte(s), response 0 byte(s), duration 0
> ms

Стадия 9 соответствует попытке отправки клиенту полностью прошедшего проверку принятого ответа от сервера.
Судя по всему, пока длилось двухминутное ожидание ответа от сервера, в «нижнем» сокете успел сработать таймаут.
Вот что в исследуемой ситуации пишет обработчик исключения:

System.Net.Sockets.SocketException: Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера
в System.Net.Sockets.Socket.Receive(Byte[] buffer)
в Always64.IrbisProxy.ReceiveAll(Socket socket, MemoryStream memory) в C:\Projects\Always\Always64\IrbisProxy.cs:строка 1172

---

Разобрался в проблеме, почистил работу с сокетами. По крайней мере, на нашем тестовом сервере нормально отрабатывает статистическая форма по базе с 1.2 млн. записей.



Редактировано 3 раз. Последний раз 14.02.2014 09:32 пользователем amironov73.

amironov73 написал(а):
-------------------------------------------------------
> Разобрался в проблеме, почистил работу с сокетами.
> По крайней мере, на нашем тестовом сервере
> нормально отрабатывает статистическая форма по
> базе с 1.2 млн. записей.

Огромное спасибо!

Протестировал ИРБИС-прокси на высоконагруженном сервере и за неделю не было никаких сообщений о проблемах книговыдачи. Единственно, что удивляет, так это отсутствие всех протоколов кроме AlwaysDump.txt. Файлы протоколов Always64.log и Search.log создаются на локальной машине и не создаются на сервере. Ситуация тем более трудно объяснимая, что путь ко всем протоколам одинаковый.

> > Должен отметить, что многие версии клиентов
> > отправляют неверное с точки зрения Прокси
> значение
> > длинны запроса.
> Можно привести конкретные примеры: какие клиенты и
> что именно посылают (мало/много)?

ИРБИС 128, Арбуз, J-ИРБИС 2.0, J-ИРБИС 1.Х, ИРБИС-Аналитика, ИРБИС-корпорация используют нестандартный, эмпирически выведенный ещё в 2006 году алгоритм определения длинны пакета. Соответственно эти пакеты через ИРБИС-прокси не проходят.

Мне так и не удалось выяснить, было ли это связанно с особенностями протокола того времени, но сейчас, к сожалению, этот атавизм везде сохранился. И, как ни странно, некорректная (меньше реальной) длинна пакета не вызывает отторжения со стороны современного ИРБИС-TCP/IP сервера.

Благодаря ИРБИС-прокси я скорректировал алгоритм определения длинны пакета. Копии J-ИРБИС 2.0 будут автоматически обновлены в течение месяца. Илья Михайленко сообщил мне, что ИРБИС 128 2014.1 так же будет выпущен с этим исправлением.

Кирилл Соколинский (СЗТУ) написал:
-------------------------------------------------------
> Протестировал ИРБИС-прокси на высоконагруженном
> сервере и за неделю не было никаких сообщений о
> проблемах книговыдачи. Единственно, что удивляет,
> так это отсутствие всех протоколов кроме
> AlwaysDump.txt. Файлы протоколов Always64.log и
> Search.log создаются на локальной машине и не
> создаются на сервере. Ситуация тем более трудно
> объяснимая, что путь ко всем протоколам
> одинаковый.

Можно увидеть Always64.exe.config и вывод команды "icacls C:\Logs"
(или где там вместо C:\Logs предполагается хранить логи) ?

> ИРБИС 128, Арбуз, J-ИРБИС 2.0, J-ИРБИС 1.Х,
> ИРБИС-Аналитика, ИРБИС-корпорация используют
> нестандартный, эмпирически выведенный ещё в 2006
> году алгоритм определения длинны пакета.
> Соответственно эти пакеты через ИРБИС-прокси не
> проходят.

Попробую как вариант решения данной проблемы сделать в будущей версии настройку: «с определенных IP пропускать клиентские пакеты "как есть"».

> Благодаря ИРБИС-прокси я скорректировал алгоритм
> определения длинны пакета. Копии J-ИРБИС 2.0 будут
> автоматически обновлены в течение месяца. Илья
> Михайленко сообщил мне, что ИРБИС 128 2014.1 так
> же будет выпущен с этим исправлением.

А вот это радует. Когда программы следуют стандартам, это значительно упрощает жизнь администраторам и конечным пользователям.

amironov73 написал(а):
-------------------------------------------------------
> Можно увидеть Always64.exe.config и вывод команды
> "icacls C:\Logs"
> (или где там вместо C:\Logs предполагается хранить
> логи) ?

Прилагаю файл настройки и пример лога (единственного).

> Попробую как вариант решения данной проблемы
> сделать в будущей версии настройку: «с
> определенных IP пропускать клиентские пакеты "как
> есть"».

Я думаю, не стоит. Стандарты есть стандарты, и все модули их должны соблюдать.

Кирилл Соколинский (СЗТУ) написал(а):
-------------------------------------------------------
>
> Прилагаю файл настройки и пример лога
> (единственного).

У меня такое впечатление, что прокси не прочитал конфигурационный файл. От какой учётной записи запускается сервис? Создаются ли логи, если запустить прокси как консольную программу?

Покажите, пожалуйста, вывод команды "icacls.exe D:\IRBIS64\logs". У нас, например, он таков:

F:\Logs>icacls.exe F:\Logs
F:\Logs BUILTIN\Администраторы:(F)
        BUILTIN\Администраторы:(I)(OI)(CI)(F)
        NT AUTHORITY\система:(I)(OI)(CI)(F)
        СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ:(I)(OI)(CI)(IO)(F)
        BUILTIN\Пользователи:(I)(OI)(CI)(RX)
        BUILTIN\Пользователи:(I)(CI)(AD)
        BUILTIN\Пользователи:(I)(CI)(WD)

Успешно обработано 1 файлов; не удалось обработать 0 файлов

У нас служба ИРБИС-прокси выполняется от имени NT AUTHORITY\LocalService, поэтому из вышеприведённого вывода icacls видно, что прокси имеет полный доступ к папке (F).

Что ещё показалось странным: в последних версиях прокси в файл дампа выводит всю свою конфигурацию:

------------------------------------------------------------
STARTED=24.02.2014 11:50:39
PROXY=1.0.8.20
CLR=2.0.50727.5472
ENVIROMENT=Microsoft Windows NT 6.1.7601 Service Pack 1
USED=17702912
receive-timeout=0
send-timeout=0
local-port=6666
backlog=10
remote-ip=127.0.0.1
remote-port=5555
dump-to=C:\IRBIS64\logs\AlwaysDump.txt
dump-general-info=True
dump-request-header=True
dump-request-body=True
dump-response-header=True
dump-response-body=True
dump-errors=False
write-access-log=True
access-log-file-name=C:\IRBIS64\logs\Always64.log
write-search-log=True
search-log-file-name=C:\IRBIS64\logs\Search.log
error-log-file-name=C:\errors.log
write-network-log=False
network-log-file-name=C:\network.log
wakeup-command=
wakeup-arguments=
wakeup-interval=300
------------------------------------------------------------
Listening on 0.0.0.0:6666

А у Вас он вывел только строку Listening...

amironov73 написал(а):
-------------------------------------------------------
> Кирилл Соколинский (СЗТУ) написал(а):
> --------------------------------------------------
> -----
> >
> > Прилагаю файл настройки и пример лога
> > (единственного).
>
> У меня такое впечатление, что прокси не прочитал
> конфигурационный файл.
Судя по тому, что один из логов он аккуратно пишет в нужную папку, файл конфигурации прочитан.

> От какой учётной записи
> запускается сервис?

NET_SERVICE (сетевая служба) Прописал для неё специально права на папку с логами. Прокси корректно пишет один лог.

> Создаются ли логи, если
> запустить прокси как консольную программу?

Да, лог AlwaysDump создаётся.

>
> Покажите, пожалуйста, вывод команды "icacls.exe

D:\irbis64\logs NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(F)
                IRSRV\roman:(I)(OI)(CI)(F)
                BUILTIN\Пользователи:(I)(OI)(CI)(F)
                BUILTIN\Администраторы:(I)(OI)(CI)(F)
                NT AUTHORITY\система:(I)(OI)(CI)(F)
                СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ:(I)(OI)(CI)(IO)(F)

Успешно обработано 1 файлов; не удалось обработать 0 файлов

> Что ещё показалось странным: в последних версиях
> прокси в файл дампа выводит всю свою
> конфигурацию:
> А у Вас он вывел только строку Listening...

Я взял лишь лог за один из дней. Конфигурация выводится корректно.

STARTED=16.02.2014 16:17:57
PROXY=1.0.8.20
CLR=2.0.50727.5472
ENVIROMENT=Microsoft Windows NT 6.1.7601 Service Pack 1
USED=16543744
receive-timeout=0
send-timeout=0
local-port=6666
backlog=10
remote-ip=127.0.0.1
remote-port=5555
dump-to=D:\IRBIS64\logs\AlwaysDump.txt
dump-general-info=True
dump-request-header=True
dump-request-body=True
dump-response-header=True
dump-response-body=True
dump-errors=False
write-access-log=True
access-log-file-name=D:\IRBIS64\Logs\Always64.log
write-search-log=True
search-log-file-name=D:\IRBIS64\Logs\Search.log
error-log-file-name=C:\errors.log
write-network-log=False
network-log-file-name=C:\network.log
wakeup-command=
wakeup-arguments=
wakeup-interval=300
------------------------------------------------------------
Listening on 0.0.0.0:6666

Как я понимаю из конфигурации, фактически параметров гораздо больше? Интересно, dump-errors может сейчас использоваться?

Кирилл Соколинский (СЗТУ) написал(а):
-------------------------------------------------------
> Как я понимаю из конфигурации, фактически
> параметров гораздо больше? Интересно, dump-errors
> может сейчас использоваться?

Да, параметр dump-errors рабочий. Если он установлен в True, в файл дампа (в Вашем случае D:\IRBIS64\logs\AlwaysDump-<дата>.txt) будут записываться стек-трейсы исключений, возникающих в прокси. Этот параметр, как и write-network-log, скорее отладочный, предназначенный в первую очередь для разработчика прокси, поэтому я его не пропагандирую.

У меня неожиданный вопрос: какая версия прокси у Вас установлена – отладочная (из папки bin\Debug) или релизная (bin\Release)? Если релизная, попробуйте заменить её на отладочную. Посмотрим, что напишет прокси в логи, вдруг что-нибудь путное.

А то у меня пока нет ни одной приличной идеи, почему в дамп пишется только базовая информация, хотя все параметры вроде dump-request-header установлены в True …

Не полностью разобрался с работой прокси-сервера ИРБИс. Но на некоторых машинах после того, как "побежал" ирбис - идет завершение работы клиента. Это равноценно тому, как нажать на кнопку закрыть. Но здесь выскакивают сообщения про закрытие клиента. При прокси - они просто завершаются без каки-либо системых сообщений. Это фича или баг? Настройки по умолчанию.
+
Можно ли указать максимальный размер файла журнала?



Редактировано 1 раз. Последний раз 23.09.2014 17:58 пользователем woodyfon.

woodyfon написал(а):
-------------------------------------------------------
> Не полностью разобрался с работой прокси-сервера
> ИРБИс. Но на некоторых машинах после того, как
> "побежал" ирбис - идет завершение работы клиента.
> Это равноценно тому, как нажать на кнопку закрыть.
> Но здесь выскакивают сообщения про закрытие
> клиента.

Прокси не добавляет от себя ни одного байта в обрабатываемые пакеты. Ничего не изымает, кроме «битых» пакетов (например, с испорченным заголовком).

Задача ИРБИС-Прокси — сделать так, чтобы проблемы со связью, возникшие у одного клиента, не повлияли на других клиентов. Сам же «проблемный» клиент может зависать, вылетать — тут Прокси бессилен, т. к. не умеет восстанавливать битые сетевые пакеты.

Аварийное закрытие клиента, скорее всего, происходит из-за того, что, получив проблемный пакет от клиента, Прокси закрывает соединение с этим клиентом. Таким образом, вместо хоть-какого ответа от сервера, приходит сигнал «на том конце внезапно положили трубку». Такое поведение сервера шокирует АРМ, и он аварийно завершается.

Наверное, можно попробовать вместо прерывания соединения отсылать код ошибки -8888 (общая ошибка). Потерянный пакет это не спасёт, но должно заставить клиента показать предложение повторного подключения к серверу.

> При прокси - они просто завершаются без
> каки-либо системых сообщений. Это фича или баг?
> Настройки по умолчанию.

Баг, конечно. В каких условиях Прокси аварийно завершается? Сколько клиентов одновременно пытаются подключиться? Какова нагрузка на процессор/память в этот момент? Или «вылетание» происходит при попытке стартовать Прокси, ещё до начала обработки клиентов?

> +
> Можно ли указать максимальный размер файла
> журнала?

Предусмотрена только ежедневная ротация журнала: например, сегодняшний журнал называется Log-2014-09-24.txt, завтрашний – Log-2014-09-25.txt. Старые журналы можно удалять по мере необходимости (вручную или какой-либо утилитой).

Другой функциональности по ограничению размера журнала не предусмотрено.

Цитата:

Наверное, можно попробовать вместо прерывания соединения отсылать код ошибки -8888 (общая ошибка). Потерянный пакет это не спасёт, но должно заставить клиента показать предложение повторного подключения к серверу.

Как это можно реализовать? Через настройки?

Цитата:

Баг, конечно. В каких условиях Прокси аварийно завершается? Сколько клиентов одновременно пытаются подключиться? Какова нагрузка на процессор/память в этот момент? Или «вылетание» происходит при попытке стартовать Прокси, ещё до начала обработки клиентов?

Имею в виду не прокси аварийно завершается, а клиента АРМ, который ходит на сервер через прокси. С самим прокси все нормально.

woodyfon написал(а):
-------------------------------------------------------
> Как это можно реализовать? Через настройки?

Только внесением соответствующего функционала в исходный код Прокси

> Имею в виду не прокси аварийно завершается, а
> клиента АРМ, который ходит на сервер через прокси.
> С самим прокси все нормально.

Полагаю, что аварийное завершение клиентов является следствием стратегии обработки ошибок в Прокси. Обнаружив неверный пакет, Прокси разрывает соединение. Сервер ИРБИС64 на это реагирует нормально, а вот клиенты, как выяснилось, могут аварийно завершаться.

Нужна новая стратегия обработки ошибок. Но какая? Вот в чём вопрос.

.....А так теперь как часики. Вообще непонятно как мы раньше работали!....

На каких каналах работает как "часики"? Какие усредненная спецификация на компьютерах у клиентов? Какая специкация сервера?

Решил попробовать Ирбис-прокси. Установил как сервис. И так и сяк вертел ничего не получается. Как я понимаю какая то проблема с портом. Брандмауэр выключен, сканировал порты на 5555 ничего не слушает. Еще смущает, что в логе пишет "remote-ip=127.0.0.1" хотя в конфиге указан другой IP. Пробовал и дебаг и релиз версии, разницы никакой.

DiemoS написал(а):
-------------------------------------------------------
> Решил попробовать Ирбис-прокси. Установил как
> сервис. И так и сяк вертел ничего не получается.
> Как я понимаю какая то проблема с портом.
> Брандмауэр выключен, сканировал порты на 5555
> ничего не слушает.

У Вас в конфиге сказано:

key="local-port" value="6666"

Это означает, что прокси должен прослушивать порт 6666, который, скорее всего, уже прослушивает ИРБИС-сервер. Естественно, Windows отказывается открывать уже занятый порт.

Перенесите либо сервер, либо локальный порт прокси на другой порт.

DiemoS написал(а):
-------------------------------------------------------
> Еще смущает, что в логе пишет "remote-ip=127.0.0.1"
> хотя в конфиге указан другой IP. Пробовал и дебаг
> и релиз версии, разницы никакой.

Спасибо за внимательность! В программе была досадная неточность при считывании настройки "remote-ip", всегда устанавливалось значение "127.0.0.1". Поскольку подавляющее большинство пользователей устанавливают ПРОКСИ на той же машине, что и сервер, ошибка оставалась незамеченной.



Редактировано 1 раз. Последний раз 03.02.2016 12:42 пользователем amironov73.

Исходные коды проекта можно также скачать (бесплатно, без регистрации) с хостинга GitHub по адресу https://github.com/amironov73/irbis-proxy.git

Алексей, а на сервере Windows Server 2012 R2 Datacenter он работает? Сегодня установила на нем, а он не работает, логи не пишутся, хотя служба запущена от системы и полный доступ к папке. На Windows Server 2008 никаких проблем не было.

Oksana2405 написал(а):
-------------------------------------------------------
> Алексей, а на сервере Windows Server 2012 R2
> Datacenter он работает? Сегодня установила на нем,
> а он не работает, логи не пишутся, хотя служба
> запущена от системы и полный доступ к папке. На
> Windows Server 2008 никаких проблем не было.

0. Видно ли AlwaysService в Диспетчере задач Windows (см. приложенный снимок экрана)?



1. Установлен ли .NET Framework, и если да, то каких версий?

2. Что говорится по поводу Always64 в Системном журнале событий (см. приложенный снимок экрана)?



3. Какие именно папки Вы имеете в виду? Ведь прокси может пытаться писать логи, например, в папку C:\Logs, если так указано в Always64.exe.config.



Редактировано 1 раз. Последний раз 29.09.2016 13:20 пользователем amironov73.

Спасибо, я разобралась уже.

С Гитхаба удалили?
Давно настраивал. Вроде была где-то инструкция?

Konstantinus написал(а):
-------------------------------------------------------
> С Гитхаба удалили?
> Давно настраивал. Вроде была где-то инструкция?

С современными версиями ИРБИС64 (2014-2015) прокси не нужен, они сами прекрасно «держат удар», спасибо авторам. Посему проект «ИРБИС-Прокси» был сочтён неактуальным и удалён с ГитХаба.

Прикреплённый к первому сообщению темы архив содержит исходные тексты. Самая подробная инструкция, какую я писал, – в приложенном к данному сообщению файле.

То есть с версией 2015.1 ставить нет смысла?

Konstantinus написал(а):
-------------------------------------------------------
> То есть с версией 2015.1 ставить нет смысла?

По моему опыту – да. ИРБИС-сервер 2015.1 без прокси работает очень прилично.

Не вполне так, коллеги.

У нас в Питере только использование ИРБИС-ПРОКСИ дает возможность реально работать.
Примерно 600 клиентских машин по городу, около 850 зарегистрированных клиентов. Да, после версии 2013 ИРБИС64 мы несколько расслабились и в тот момент убрали его, но уже в этом году единственное, что нас вывело из тупика — ИРБИС-ПРОКСИ.
Плюс сервер в режиме приложения. Опять же оказалась, что существенно отличается по стабильности работы на большой нагрузке (книговыдача в дневные часы окло 200-250 экз./мин.) от режима службы.


А попутно еще нашли применение для этой замечательной программы: вместо записи в текстовый лог она пишет теперь трассировку поисковых запросов в БД MS SQl, что дает статистику читательского поиска, о которой так давно мечтали наши библиографы.

Так что, не торопитесь отказываться от ИРБИС-ПРОКСИ.

И еще раз большая благодарность Алексею Владимировичу Миронову за столь качественный продукт.

---
Линно
Константин Гуннарович,

ЦГПБ им. В. В, Маяковского,
Санкт-Петербург

Linno K. написал(а):
-------------------------------------------------------
> Плюс сервер в режиме приложения. Опять же
> оказалась, что существенно отличается по
> стабильности работы на большой нагрузке
> (книговыдача в дневные часы окло 200-250
> экз./мин.) от режима службы.

Ого, у Вас нагрузки! На наших нагрузках, которые заметно меньше, уже вполне можно работать без Прокси.

> А попутно еще нашли применение для этой
> замечательной программы: вместо записи в текстовый
> лог она пишет теперь трассировку поисковых
> запросов в БД MS SQl, что дает статистику
> читательского поиска, о которой так давно мечтали
> наши библиографы.

Есть предложение – опубликуйте исходный код Вашей доработки, хоть здесь, хоть на ГитХабе, полагаю, найдутся те, кому она пригодится.

Ну, с кодом все просто.

1. Изменения в Irbisproxy.cs совсем простые:

Изменение коснулось только DoSearchLog: текст в прикрепленном файле.

Поскольку статистика книговыдачи у нас давно уже выведена из ИРБИС, и мы сводим все потока данных на один сервер статистики, то и данные читательского поиска тоже направляем туда.

2. Во втором файле серверная часть. (MS SQL Server 2012)

Краткие комментарии везде есть. По возможному использованию данных, кроме двух имеющихся вариантов, пока наши библиографы думают.
По сути — одна ХП используется ИРБИС-ПРОКСИ для ззаписи в БД, а две — статистические выборки, по БД и словарям.
Алгоритм вычленения префиксов написан на скорую руку, наверное, регулярные выражения бы улучшили результат.

3. Собственно сами статистические данные в двух файлах Excel.
SearchByDB - распределение читательских поисков по БД ЭК.
SearchByDic - по используемым словарям.
SearchByDicFull - по используемым словарям, с учетом имеющихся ошибок
разбора поисковых запросов. Несовершенство алгоритма разбора хорошо заметно именно в этом файле.
P.S.
И тут именно я увидел, что можно прикрепить только три файла ((
Два последних файла придется, увы, в следующем сообщении выложить.

---
Линно
Константин Гуннарович,

ЦГПБ им. В. В, Маяковского,
Санкт-Петербург

Вот, собственно, два примера для предыдущего сообщения.

---
Линно
Константин Гуннарович,

ЦГПБ им. В. В, Маяковского,
Санкт-Петербург