Василий Каменев пишет:
ничего подобного, смысл заключается в том что:
1. определяется поле срабатывания "как всегда".
2. в действие рула добавляется ссылка на "линкер".
3. линкер связывает поле из п.1 с доп. формами.
по идее, начинают с п.3. и что в этом линкере будет описано на то ( в вашем случае на то состояние ) он и будет срабатывать.
По пункту 3, по старой версии правила (которое сейчас не срабатывает и выдаёт ошибку) в generic relation стоит следующая связка:
From Item - Status
To Item - Form
В правиле стоит срабатывание этой связки на изменение флага FAQ (добавляется ещё одно поле при статусах "Работы выполнены" и "Закрыта"). Что именно нужно поменять в правиле или generic relation не совсем понимаю - можно привести пример?
P.S. выставить в generic relation зависимость сабформы от флага невозможно.
Григорий Ненашев пишет:
Тут вопрос встанет в производительность БД, и оптимизации запросов, расчет на 1 APP 70 сессий, Объем FTP рассчитать также можно, взять данные за неделю с разбивкой по дням и сделать средне значение + 30% на увеличение. При таких объемах, я бы в системе включил все возможные блокировки, ради уменьшения нагрузки на базу.
Блокировки в самой БД, как понимаю? А не будет ли это вызывать ошибок в клиенте или зависаний?
Здравствуйте. Давно я у вас не появлялся тут
Руководство поставило задачу рассчитать необходимые ресурсы для расширения области применения SD.
Цифры меня несколько ужаснули - планируется, что будет дополнительно 120к заявок в месяц (текущий объём 30к) и около 200 Гб данных ежемесячно на фтп, а также около 1000 клиентских сессий одновременно.
На данный момент у меня в архитектуре 4 физических сервера, на которых подняты 8 серверов приложений (6 для толстого клиента, 2 под web-интерфейс) и 2 сервера БД в кластере (MS SQL 2008). Порядка 300 одновременных сессий (как раз по 50 на каждое приложение).
Собственно, вопрос: если я подниму дополнительно 20 серверов приложений на этих же физических серверах, этого хватит или нужно ещё какие-нибудь манипуляции проводить? Ну и в догонку - возможно ли работа SD (ftp) с несколькими дисковыми массивами?
Григорий Ненашев пишет:
Когда у меня была такая проблема, я частично перевел правила с Scheduled Tasks на JOB. Переписал полностью все правила DB на более оптимальные. Удалил 80% правил UL и перевел их на работу через бизнес логику системы.
Одно правило UL заменило % 60 правил на ограничение, в замен, того что было. Также оптимизировал базу для поиска, например если в поисковой форме где номер указывается в промежутке поиск работал, скажем сек 6 теперь 1 сек. Т.е стал работать как я бы искал через расширенную форму поиска с однозначным условием.
Для всех представлений как системных так и пользовательских на кастумные поля добавил индексов. (часто используемые в представлениях) Тогда представление у пользователей грузиться мгновенно,
Зависание app серверов происходит крайне редко. – Что не может не радовать, я их даже не перезапускаю автоматически. По прикладам это 6 серверов для работы с пользователями и 2 для почты.
Мне кажется, что зависание происходят из-за DB правил, простой пример, хотим видеть всех активных специалистов в онлайне по группе: В карточку заносим поле типа персонал, пишем правило на внесение в это поле сотрудника который изменил форму, и DB правилом уже пишем дату изменения в карточку пользователя. Вот теперь если специалист будет групповой правкой в объектах что-то править, то мы вызываем чумовую нагрузку на данное правило… может привести к зависанию сервиса. (проверял, работает).. «Есть свои нюансы».
Спасибо. Давно хотел уже заменить кучу правил интерфейса каким-нибудь одним-двумя стандартными, теперь будет повод
1. Вроде ява в 32-х разрядной системе больше гигабайта выжрать и не сможет
2. Перезапускается автоматически в 7 утра
3. Вариант, да. Но их уже 8 (по 2 на каждом физическом сервере). Да и отложенных заданий приходится на каждый не более 2000.
Добрый день. С недавнего времени стал подвисать один из серверов приложений. В логах не особо много информации, сразу после перезапуска сервиса, выдаётся следующая ошибка (но это, я так понимаю, оттого, что клиенты пытаются соединиться заново под старыми сессиями):
Вт, 21/02/2012 09:52:37 <Data Access> JDBC error 547: []The INS ERT statement conflicted with the FOREIGN KEY constraint "SES_SVI_OID_FK". The conflict occurred in database "sdctdb", table "dbo.REP_SERVERS", column 'SVI_OID'., SQL state: 23000 for query: INS ERT INTO rep_sessions
( ses_oid
,ses_markedforremoval
,ses_svi_oid
,ses_client_ipport
,ses_server_ipport
,ses_client_ipaddress
,ses_isconcurrent
,ses_threadname
,ses_server_ipaddress
,ses_acc_oid
,ses_created
,ses_lockseq
) VAL UES ( ?
,?
,?
,?
,?
,NULL
,0
,?
,?
,?
, CONVERT(DATETIME,?,120)
,?)
Val ues:
?1601223823
Иногда перед зависанием в логах можно увидеть такую ошибку:
Вт, 21/02/2012 09:44:49 <ITP> IO Stream Exception: itp://хх.хх.хх.хх:1422
Вт, 21/02/2012 09:44:49 <Trace> ITPcom.hp.ifc.io.AppStreamException: Flush failed due to: Connection reset by peer: socket write error
at com.hp.ifc.io.AppDataStream.flushError(Unknown Source)
at com.hp.ifc.io.AppDataStream.flushBuffer(Unknown Source)
at com.hp.ifc.io.AppDataStream.write(Unknown Source)
at com.hp.ifc.net.itp.AppItpRequestHandler.sendResult(Unknown Source)
at com.hp.ifc.net.itp.AppItpRequestHandler.process(Unknown Source)
at com.hp.ifc.net.tcp.AppTcpConnection.processRequest(Unknown Source)
at com.hp.ifc.net.tcp.AppTcpThread.run(Unknown Source)