8.х Вызов сервером обработчика события на клиенте

Тема в разделе "Конфигурирование на платформе "1С:Предприятие 8"", создана пользователем sobenko, 1 мар 2012.

  1. alexburn
    Offline

    alexburn Модераторы Команда форума Модератор

    Регистрация:
    5 янв 2009
    Сообщения:
    14.771
    Симпатии:
    509
    Баллы:
    204
    Блин, может перестанете:)))))) ?
  2. vartanet
    Offline

    vartanet Опытный в 1С Команда форума

    Регистрация:
    16 ноя 2010
    Сообщения:
    2.698
    Симпатии:
    15
    Баллы:
    29
    да ладно ;) послушать то прикольно. только мне совсем не понятно, почему sobenko за..бывает разработчиков прикладных решений, а не разработчиков платформы.


    нравится если - пусть использует свой сокет (если есть такая возможность). не нравится - пусть идет лесом.
  3. vartanet
    Offline

    vartanet Опытный в 1С Команда форума

    Регистрация:
    16 ноя 2010
    Сообщения:
    2.698
    Симпатии:
    15
    Баллы:
    29
    и вот ещё:

    "В конце ноября 2010 Adam Barth опубликовал результаты исследования надежности используемого протокола. По его результатам выяснилось, что в случае использования прозрачных прокси-серверов, возможна подмена кеша передаваемых данных с тем, что пользователи вместо реальных данных будут получать версию данных от злоумышленника. Проблема оказалась достаточно серьёзной для того, чтобы разработчики Firefox и Opera объявили о том, что в будущих версиях их браузеров поддержка веб-сокетов будет по умолчанию отключена вплоть до устранения проблемы небезопасности данного протокола (хотя осталась возможность их включить)."

    _http://ru.wikipedia.org/wiki/WebSocket
  4. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Ничего не понял. Вы хотите, что бы сервер SQL обрабатывал некие подписки на манер триггеров? Он-то откуда что-то знает о каких-то клиентах 1С?

    Вы путаете теплое с мягким. Уже устал это объяснять. Абсолютные числа без процентного соотношения не имеют никакого смысла.
    Именно поэтому и придумана методика APDEX, которая позволяет выявлять критические места. Изучите эту методику.

    Коллеги Вам уже объяснили и я еще раз повторю: без паттерна использования реализовать что-то будет только бестолковый разработчик.

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

    Мое число 100500. Оно круче. Что дальше? Вы считаете это аргументом? Я вот тоже нет.

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

    Кто говорит о практике? Вы в теории даже задачу необходимую придумать не можете! Те, которые привел - успешно решены без каких-либо выдумок.

    Мне нравиться механизм доводчиков дверей. Сделайте в платформе, что бы она умела управлять регулировками электронных доводчиков.
    Зачем? Да есть преимуществ же! Какие? Как какие? Регулировка!
    Вот и Ваши слова такие же. Преимущства есть (никто не спорит) - но не для платформы.

    Возможно, но задачи, которой требуется такое решение - не привели. Вывод -> не требуется.

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

    Слушать его не станут. Ибо без паттерна использования и ощутимых выигрышах - толку от этого ноль. Что тут и объяснено уже миллион раз.
  5. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Наличие любого опыта (даже отрицательного) в абсолютно любой области всегда дает преимущество, т.к. человек познает мир в сравнении, а наличие опыта позволяет сравнивать настоящее с предшествующим и находить наилучшее решение. Почитайте теорию распознавания образов, экспертных систем и т.п. Все новое это хорошо забытое старое.
    Снова разорвали один абзац на две части по этому цитата приобрела совершенно иной смысл. Я Вас цитирую целыми абзацами, а так можно из абзаца "надергать" кусочков и они будут нести уже совершенно иной, нужный Вам смысл.
    Снова внимательно читаем мои посты. В который раз я буду повторять что я не выкидываю начисто обращения клиента к серверу. Само понятие асинхронного обмена не предполагает такого. Асинхронный обмен в общем случае означает инициацию обмена любой из сторон, а не одной! Когда только одна сторона инициирует обмен это называется синхронным методом обмена!
    Еще раз "на пальцах" поясняю принцип работы:
    1) При старте системы (или открытии определенной формы списка) клиент инициирует запрос к серверу и получает текущий набор данных.
    2) Клиент подписывается на определенное событие, указывая какие именно изменения данных его интересуют (с указанием фильтра) и процедуры- обработчика. При этом происходит запись в служебную таблицу БД пользователя, номера сеанса, описание события и фильтра. Таблица индексируется, что обеспечивает в будущем максимальную скорость выполнения запросов к ней.
    3) Когда на каком-либо клиенте происходит указанное событие рабочий процесс на сервере выполняет запрос к служебной таблице и получает список всех подписавшихся на событие клиентов (сеансов). Далее рабочий процесс отсылает оповещения по полученному списку сеансов. Если соединение в момент оповещения вдруг оборвалось, то рабочий процесс делает то-же самое, что и в случае когда клиент передал серверу запрос и "отвалился", не получив результат запроса.
    4) Когда клиент получает оповещение, на нем запускается указанная при подписке процедура обработки события (которая физически может выполняться на сервере, если это указано директивой). Именно эта процедура и выполняет либо обычный запрос, получая нужные новые данные, либо выполняет обновление формы (также как это сейчас происходит при нажатии на кнопку "Обновить" на форме, использовании метода Обновить() и т.п.). Что именно делать- разработчик пишет в процедуре.
    5) При отписке от обработки события из служебной таблицы происходит удаление соответствующей записи. Удаление всех записей с соответствующим пользователем и номером соединения происходит также при удалении/закрытии соединения, повторной подписке на то-же событие и т.п.
    6) Ни что не мешает клиенту по мимо асинхронного механизма выполнить запрос по тем-же данным в любой момент времени, если так напишет приложение разработчик.

    По поводу Ваших данных о загруженности сервера на 0.5% давайте подсчитаем минимальное время выполнения запроса по классу объектов "Задача", "Документ", "Регистр ..." (если на клиенте открыто несколько форм или одна обобщающая форма типа "Рабочего стола", на которых необходимо обеспечить актуальность данных и вычислим максимальное число клиентов, которые загрузят сервер на 20%. Число клиентов буде далеко не миллионы или тысячи.
  6. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Это 2010 год. Поставьте последнюю версию Firefox и Opera и зайдите на сайт www.mibbit.com (чат на основе протокола WebSocket) Вы удивитесь, но он работает! Вывод: сегодня протокол уже поддерживается, т.к. он имеет статус "Предложенного стандарта" и проблемы безопасности 2-х летней давности давно решены! Читайте http://www.rfc-editor.org/info/rfc6455 и http://www.rfc-editor.org/info/rfc6454.
  7. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Накладные расходы не учитываем на запись, индексацию? Почему?

    Почему нет описания накладных расходов?
    Пример на остатках:
    Клиент подписался на событие обновления остатков
    Происходит изменение остатков
    1. Сервер анализирует таблицу подписок, накладывает фильтры
    2. Пытается достучаться до клиента (связь неустойчивая, знаю реальные примеры, когда факт установки соединения занимает времени больше, чем сама передача данных)
    3. Клиент обрабатывает событие
    4. Лезет на сервер за новыми данными

    Теперь представим, что пользователей-то у нас много, изменения постоянно идут (продажи, перемещения, поставки, резервы)
    Таким образом, 10 подобных событий в секунду - это нормально. (А уж если массово документы будут перепроводить - вообще атас!)
    Вроде как очевидно, что производительность будет значительно ниже и это как раз и показывает гуглдокс, который дергает клиента каждый раз при изменении в тексте.

    Далее, предположим, что ввели фильтр на время обработки события. Получаем:
    1. Сервер анализирует таблицу подписок, накладывает фильтры
    2. Анализирует последнее время события
    3. Пытается достучаться до клиента (связь неустойчивая, знаю реальные примеры, когда факт установки соединения занимает времени больше, чем сама передача данных)
    4. Клиент обрабатывает событие
    5. Лезет на сервер за новыми данными

    Становится еще хуже. А ведь это только ОДНО событие для ОДНОГО клиента.
    А пользователей у нас много, подписок много и на этом моменте сервер сдыхает, не говоря уже о том, что смысл от такой "фишки" теряется при вводе задержки.

    Подводя итог: очевидно по сценарию, что накладные и побочные затраты вырастают на порядок, если не на несколько!
    Если не хотите проверять на гуглдокс - проверьте тупо запросов в событии ПриВыводеСтроки, что будет происходить.

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

    При вызове самого клиента - выше написал, что происходит. Вызов на сервере- вообще непонятно зачем. Причем тут клиент - это чисто серверная операция.

    Что делать, если соединение было некорретно завершено? Сервер будет долбиться в запертную дверь? Или напишем обработчик таких ситуаций с неким анализом и получим еще накладные расходы?

    Нафига тогда вообще было городить огород?

    Наверное, тут должно быть слово "минимальное".
    Тут еще раз надо понять: все зависит от архитектуры.
    При активных 400+ пользователях (сегодня днем смотрел как раз) - нагрузка на сервере составляет около 70%. При этом пользователи выполняют весьма тяжелые операции + висят обработчики.
    Так что тут все зависит от кривости рук...

    Подводя итог: накладные расходы превышают выгоду.
  8. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    Мы вроде в этой теме беседуем не об общем развитии человека, а об 1С. Поэтому в данном конкретном случае эта нить ваших рассуждений и вывод не к месту. Или вы хотите сказать, что мастер спорта по фигурному катанию будет иметь преимущество перед учащимся ПТУ, окончившем 9 классов, если перед ними обоими поставить задачу проектировки учетной системы, потому что у первого больше опыта в определенной области?



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


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



    Ну наконец то. Мы пришли к этому. Давайте. О том что неплохо бы увидеть практические результаты ваших экспериментов, подтверждающие полную неэффективность текущих возможностей платформы было сказано давно.


    Эммм.. Или я недопонял эту последнюю фразу - и это предлагается сделать мне?

    З.Ы.

    И кстати, если не пропустите, прокомментируйте пожалуйста поподробней вот этот вопрос, заданный вами предыдущим оратором:
  9. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Мне становится не интересно спорить с человеком, прекрасно понимающим о чем речь, но постоянно переворачивающим смысл написанных мною фраз. Вы этому у политиков научились? Так здесь вроде другие люди общаются.
    К чему вспоминать о "накладных расходах" SQL сервера, когда речь идет только о процессах на клиенте и сервере 1С?! Вы сюда еще затраты электроэнергии припишите, они ведь есть при асинхронном обмене и напрочь отсутствуют при синхронном :))))
    Это не описание не соответствует моему описанию:
    1. Сервер анализирует таблицу подписок, накладывает фильтры
    2. Анализирует последнее время события
    На самом деле это 1 запрос, и цикл его обработки причем зашитый в платформу (т.е. скомпилированный)
    3. Пытается достучаться до клиента (связь неустойчивая, знаю реальные примеры, когда факт установки соединения занимает времени больше, чем сама передача данных)
    Происходит тоже, что и сейчас при возврате сервером результата при неустойчивой связи
    4. Клиент обрабатывает событие
    5. Лезет на сервер за новыми данными
    4- это название процесса а 5 его часть (под-процесс). Тогда напишите 4.Клиент; 5.Обрабатывает; 6.Событие. Так еще больше пунктов получится :))))

    Такое впечатление что смысл словосочетания "то-же самое" Вам непостижим. Читайте тогда словарь Даля. Что делать если... уже решили разработчики платформы и это уже работает!

    Фраза "При вызове самого клиента - выше написал, что происходит. Вызов на сервере- вообще непонятно зачем. Причем тут клиент - это чисто серверная операция." вообще убивает. Вы не в курсе что такое директивы компиляции (о чем написано мною)? Снова чушь какую-то пишите, делая вид что не поняли о чем речь.

    И самое главное: я сомневаюсь, что вменяемый разработчик додумается написать в запросе к виртуальной таблице вместо параметров таблицы- длинное условие, что приведет к бешеной нагрузке на сервер. Это 2 бала на экзамене! Аналогично вменяемый разработчик и не подпишется на КАЖДОЕ событие записи в регистр, в который запись происходит с постоянной частотой 10 транзакций в секунду, т.к. будет прекрасно понимать, что это "положит" систему. Если надо, то для такого случая делается подписка с указанием минимального интервала между событиями (к примеру 10 секунд). Клиент оповещается при этом не чаще, чем 1 раз в 10 секунд. Также вменяемые разработчики не подписываются (сейчас) несколько сотен раз на обработку события "При записи" для всех документов. Так что еще раз повторяю: У ВСЯКОГО МЕХАНИЗМА ЕСТЬ СВОЯ ОБЛАСТЬ ПРИМЕНЕНИЯ! По этому не надо пытаться нагрузить на велосипед то, что возит БЕЛАЗ.
  10. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Вы реально не понимаете проблемы?
    Тогда изучите матчасть. Эти слова только подтверждают, что Вы просто не понимаете СУТИ выполняемых действий, а уже беретесь выдавать какие числа и прогнозы.

    Какой именно сервер это выполняет? У меня их 4 в кластере!
    Запрос где выполняется? На SQL сервере. Нагрузка есть? Есть. Получаем, что на каждую подписку делаем запрос или тратим время на вычисления запроса, который должен получиться. Опять расходы времени.

    А что сейчас происходит? Вы, вообще, работали в управляемом приложении?


    На этих словах я константирую следующее:
    1. Вы не знаете матчасть
    2. Вы не знаете, как работает управляемое приложение (это к к директивам компиляции - для УП они не используются в том виде, как в обычном. Там используются директивы для процедур/функции. Изучайте матчасть)
    3. Вы недогоняете, что если обработчик есть на сервере - то нафига какая-то подписка от клиента?

    Вы знаете, как устроена работа виртуальной таблицы? Вы знаете зависимости ее исполнения от рассчитанных итогов/агрегатов? Вы знаете зависимости от режима разделения итого? ВЫ знаете отличия СреПоследних/Первых от других виртуальных таблиц?
    Когда узнаете, поймете, что для таких операций, как Вы хотите использовать, применяются реальные таблицы.

    Правильно, вот и не надо грузить на 1С то, что ей не нужно.
    Я Вам привел реальные данные в реальной системе на большом количестве пользователей. У меня проблем с реализацией и скоростью нет.
    От Вас слышны только сферические кони в вакууме с от балды взятыми числами.

    sobenko, пользователь переведен в режиме премодерации сообщений. Публиковаться будет только сообщения с реальной задачей. Прочее будет модерироваться и удаляться.
    Разговор зашел в тупик, так как Вы просто не знаете матчасти и не можете даже в теории придумать пример, который требует такой реализации от платформы.
  11. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    //вырезано shurikvz
    Все рассуждения о дворниках и русском языке убрал как явный оффтоп.


    По поводу фразы "Как клиент должен потом получить нужное ему событие, если связи в момент самого события не было?" снова повторяю уже написанное: как по Вашему клиент должен потом получить нужный ему результат запроса, если связь после передачи запроса клиентом на сервер пропала? Эту ситуацию платформа сейчас разруливает. Так почему платформа не сможет разрулить аналогично ситуацию с пропадением связи в момент наступления события точно таким-же образом?
  12. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    9:00 - проведены банковские документы, да не важно какие, любые документы, которые должны сформировать событие о котором нужно оповестить.
    9:01 - клиент только вошел в программу.

    Как клиент, вошедший в 9:01, узнает о том что нужное ему событие уже было завершено (в 9:00). Ведь согласно алгоритму подписывается он на событие только при входе. Таким образом критически важное для него событие он пропустил и о нем не узнает.
  13. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Укажите КОНКРЕТНЫЙ порядок действий.
    Сразу уточню - в режиме обычного приложения: программа закрывается. В режиме управляемого приложения (тонкий клиент) - клиент спрашивает, что там происходит у сервера.

    Разберем несколько ситуаций:
    1. В 09:00:00 событие
    2. Регистрация клиента в 09:01:00
    С этим проблем нет - ведь мы прочитаем на входе свежие данные

    Продолжим (дополним подписку тем, что не чаще одного раза в 2 сек)
    3. Происходит событие в 09:01:01
    Вот тут происходит что-то странное...

    Сервер находит нашу подписку, смотрит, что время (2 сек) еще не прошло и не сообщает клиенту.
    Клиент же, в свою очередь, сам данные не запрашивает.

    Получается, что до нового события в 09:00:02 мы ничего не узнаем, а если в 09:00:02 (или позже) ничего не произойдет - то мы вообще не узнаем про этом событие в 09:00:01
    Выходим на то, что сервер в 09:00:02 (даже если нового события не происходило) - должен дернуть клиента.
    Теперь вопрос - чем это отличается от того, что клиент спросит актуальные данные?
    Только тем, что серверу ДОПОЛНИТЕЛЬНО (помимо всех остальных расходов, которые уже описывал) - придется учитывать такие ситуации.

    Таким образом, мнимый выигрыш производительности теряет вообще все какие-либо преимущества при таких задачах.
  14. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    BabySG, когда я писал комментарий, тут я наверно не до конца сформулировал мысль, я имел ввиду следующее, возьмем как описывает процесс ТС:
    Т.е. что я имел ввиду, еще раз:
    9:00 - проведены банковские документы, да не важно какие, любые документы, которые должны сформировать событие о котором нужно оповестить.
    9:01 - клиент только вошел в программу.

    Т.е. согласно алгоритму ТС, в 9:00 выполнится п.3 и ничего не будет выслано (поскольку на 9:00 подписок нет). В 9:01 клиент заходит, для него выполняется п.2. Но как теперь клиент узнает, что было какое-то событие, если это событие за сегодняшний день уже не возникнет (т.е. если на примере тех же банковских документов - провели с утра выписку один раз и все, сегодня больше движения по этим документам не будет).
    Или имеется ввиду, что в тот момент когда клиент будет подписываться на событие (п.2), сразу после подписки для него будет один раз принудительно выполняться п.4 (т.е. минуя п.3)? Тогда понятно, у меня по этому моменту вопроса больше нет.
  15. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Ответ на Ваш вопрос, который еще раз подтверждает что Вы даже не попытаетесь понять в полном объеме описанную мною методику и рамки ее применения, находится в посте http://www.1c-pro.ru...__p__204631(п.1)!
    И пожалуйста, прочтите все посты еще раз от начала до конца темы (их пока не много, и многое в них повторяется, т.к. приходится "разжевывать" одно и тоже по нескольку раз). Затем возьмите чистый лист бумаги, опишите и нарисуйте на нем схему взаимодействия клиентов и кластера, так как ее описываю я, а не искажаете Вы и BabySG.
  16. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    sobolenko, я Вам задал конкретный вопрос по Вашей же задаче.
    Что делать в пункте 6?
    И привел пример, что будет происходить - обоснуйте, в чем я неправ.

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

    Подводим итог:
    1. От Вас требуется реальная задача
    2. Обоснуйте, в чем я не прав в сообщении 73

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

    PS. Беглый поиск показал, что Вы себя так ведете на всех площадках. Это не делает чести.
  17. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Какая "мат. часть"?
    Я абсолютно полно описал механизм взаимодействия клиента и кластера.

    Я рассматриваю работу механизма в пределах ОТ КЛИЕНТА ДО КЛАСТЕРА 1С:Предприятие (в начале я употребил слово "сервер", но имел в виду именно кластер, без рассмотрения процессов внутри него и за его пределами).

    Главное отличие профессионала от любителя состоит в том, что профессионал сначала читает, изучает, представляет или рисует для себя предмет обсуждения, а только потом высказывает какое-либо мнение.

    На самом деле Вы показываете непонимание мат.части.
    1) Что, платформа 8.2.15 позволяет работать конфигурациям только в режиме управляемого приложения?! Я не писал, что рассматриваю работу механизма только в режиме управляемого приложения (попробуйте найти мой пост, где я пишу иное)! И самое главное Ваших "перлов": откройте синтаксис-помощник в конфигураторе и прочитайте что такое директивы компиляции, что такое инструкции препроцессору и особенности их совместного использования. Для Вас будет невероятным удивлением, что в режиме управляемого приложения используются и директивы и инструкции, что Вы можете наблюдать к примеру в конфигурации "Документооборот".

    2) Я Вам, Профессионалу (с большой буквы!) должен читать лекцию как сейчас реагирует платформа на обрывы соединений?! Вы же сами утверждаете что знаете все о платформе!

    3) Вы снова строите из себя мягко говоря ничего не понимающего человека. Вы увидели словосочетание "виртуальная таблица", вырвали его из абзаца и сами придумали что я предлагаю подписку на событие делать для виртуальной таблицы. Где Вы прочли что я такое писал?! Снова подтасовка слов, вместо конструктивного, по теме, обсуждения.

    "И самое главное: я сомневаюсь, что вменяемый разработчик додумается написать в запросе к виртуальной таблице вместо параметров таблицы- длинное условие, что приведет к бешеной нагрузке на сервер. Это 2 бала на экзамене! (эти 2 предложения являются примером некорректного написания кода. А вот далее идет речь о предмете обсуждения) Аналогично вменяемый разработчик и не подпишется на КАЖДОЕ событие записи в регистр, (Здесь Вы сделали вывод что если в 1-м предложении речь идет о виртуальной таблице, а в этом о регистре, то это можно связать в одну кучу. Тогда действительно получается что я пишу о записи в виртуальную таблицу.

    А я хочу общаться с профессионалом- разработчиком 1С.

    в который запись происходит с постоянной частотой 10 транзакций в секунду, т.к. будет прекрасно понимать, что это "положит" систему. Если надо, то для такого случая делается подписка с указанием минимального интервала между событиями (к примеру 10 секунд). Клиент оповещается при этом не чаще, чем 1 раз в 10 секунд. Также вменяемые разработчики не подписываются (сейчас) несколько сотен раз на обработку события "При записи" для всех документов.
  18. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Если это по поводу поста http://www.1c-pro.ru/topic40148.html/page__view__findpost__p__205162, то поясняю: Вы чего-то решили что после подписки на событие должен запустится таймер. Я такого не писал! Я писал что:
    1) при наступлении 1-го события отсылается уведомление клиенту и запускается таймер на время, указанное при подписке на событие.
    2) Клиент запрашивает и получает данные, которые включают в себя изменения по первому событию. Также, если за время от первого запроса до окончания выполнения запроса произойдет несколько событий- то он получит и новые данные этих событий.
    3) До тех пор, пока таймер не отсчитает указанное время, клиенту не отсылаются уведомления, если происходят те-же события. Когда таймер закончит отсчет, клиенту отсылается уведомление и он получит данные, уже с учетом всех изменений, что произошли за указанное время.
    4) Если за время отсчета таймера не происходит ни одного события- клиенту уведомление не отсылается.

    Вот как отработает описанная Вами ситуация:
    1. В 09:00:00 событие
    2. Регистрация клиента в 09:01:00
    С этим проблем нет - ведь мы прочитаем на входе свежие данные

    Продолжим (дополним подписку тем, что не чаще одного раза в 2 сек)
    3. Происходит событие в 09:01:01

    При наступлении события в 09:01:01 клиент получает уведомление и запрашивает свежие данные. Запускается таймер на 2 сек. Если до 09:01:03 произойдет хотя-бы одно событие, то клиент получает новое уведомление, в 09:01:03 и снова запрашивает данные, включающие в себя все изменения, вызванные событиями от 09:01:01 до 09:01:03.
    Схему я не усекал, а не расписывал до мельчайших подробностей. Знаете, в чем разница между блок-схемой и принципиальной схемой к примеру процессора? Так вот у меня пока блок-схема, описывающая процесс от начала и до конца. Если расписать ее до малейших подробностей, то это уже будет алгоритм для реализации готового код, который останется только написать. Но я не углубляюсь пока до такого уровня, т.к. вижу у Вас не понимание общих принципов работы предложенной мною схемы взаимодействия.
    Я задачу (о подписке на новые задачи (это класс объектов такой в 1С) уже описывал. Повторять не вижу смысла. Просто читайте тему.
    Я уже описал подробно в чем Вы не правы.
  19. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Вот именно опишите ПОЛНОЕ взаимодействие.
    Кластер может быть не один - есть еще резервные кластера. Процесс на сервере может быть не один, а серверов может быть много.
    Вот окгда опишите, как все это взаимодействует - тогда и будет полное описание. А сейчас - филькина грамота.

    Не путайте директивы #Если КЛИЕНТ с директивами &НаКлиенте
    Первая указывает КОГДА требуется выполнять код, вторая указывает ГДЕ.
    Это совершенно РАЗНЫЕ понятия.
    Поэтому откройте документацию и прочитайте.
    http://its.1c.ru/db/v8doc#content:695:1:IssOgl3_4.8.1.1.%20%D0%A0%D0%B0%D0%B7%D0%BB%D0%B8%D1%87%D0%B8%D0%B5%20%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D0%B9%20%D0%BF%D1%80%D0%B5%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1%80%D0%B0%20%D0%B8%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%20%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D0%B8
    Это, кстати, тоже называется матчасть.

    Расскажите. Также расскажите это партнерам, у которых миллион проблем с некорректным завершением работы. Вы умнее всех?


    Даже комментировать не буду больше подобный бред.

    Разработчики платформы даже не посмотрят на Ваш текст в такой манере. И правильно сделают.

    Эту ситуацию я уже описал. Прочитайте внимательно еще раз последние сообщения
  20. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Т.е. предлагаете запускать тысячи таймеров! (в масштабах 500+ пользователей на трех сервера в кластере с двумя процессами - будут десятки тысяч таймеров, ибо неизвестно, на какой процесс придет следующий вызов сервера)

    Первый сервер упал - управление перешло на второй. Что делать? Новый таймер? Не годиться. Старый? Смотри выше.

    Какое уведомление? У нас явно указано, что не надо дергать раньше, чем через 2 секунды! А если будут дергать ранее - смсл от таймера? Вы начинаете противоречить сами себе.

    Еще раз: это не задача, это решение. Задача - это когда есть некая цель, которая требует такого решения. Поэтому не стоит подменять понятия.

    Для тех кто в танке:
    1. Опишите задачу, где такое надо.
    2. Изучите разницу при работе в толстом и тонком клиенте
    3. Научитесь аргументировать вести диалог, а не из серии "Я Дартаньян"


Поделиться этой страницей