Не, html и должен оставаться, убивается content.txt. в тхт нет смысла, т.к. создаются 2 файла и content.txt и content.html, при отправке в html формате. файл оставлен потому что в текст вставляют картинки и если их больше чем 1 то понять очерёдность картинок бывает трудно. СД разделит картинки и текст в разные файлы, так что целостность html файла нарушится. таково было пожелание заказчика и я думаю он прав.
Пользователь
Поиск по сайту
Реклама
Опрос
Погода
Василий Каменев (все сообщения)
| |||||||||||||||||||||
|
|
HTML->TXT при регистрации servicecall, Преобразование почтовых сообщений отправленных на регистрацию в Service Desk в TXT
|
|
|
|
|
|
HTML->TXT при регистрации servicecall, Преобразование почтовых сообщений отправленных на регистрацию в Service Desk в TXT
|
на 100% уверен что hotfix загрузился - удалять разрешает этот файл?
какой пак стоит? |
|
|
|
|
HTML->TXT при регистрации servicecall, Преобразование почтовых сообщений отправленных на регистрацию в Service Desk в TXT
|
я вчера выкладывал 2-й hotfix, но его нет, странно это
повторяю, возьми этот, процедура та же. |
|
|
|
|
HTML->TXT при регистрации servicecall, Преобразование почтовых сообщений отправленных на регистрацию в Service Desk в TXT
|
Алексей, вы просили "таблетку" - я вам её даю. в любом СП есть эти классы, но они не исправляют того что вам надо. втом-то и смысл, что нотфикс перегружает классы сп.
|
|
|
|
|
HTML->TXT при регистрации servicecall, Преобразование почтовых сообщений отправленных на регистрацию в Service Desk в TXT
|
вот либа скомпилирована под Яву 1.5, сохрани в server\lib как hotfix.jar.
сделай рестарт апп серверу. после того как сервер загрузится попробуй удалить hotfix.jar из lib\ каталога, если сервер обругает что файл занят, тогда он загрузил его и можно тестить. |
|
|
|
|
Авторизация Service Desk + AD
|
т.к. СД не имеет встроенно LDAP авторизации, то такие системы, у которых базы учёток разные авторизируются так:
Untitled.png (19.83 КБ) [ Скачать ] |
|
|
|
|
Странный глюкан, вешается сервер
|
hp OpenView service desk 4.5 server
hp OpenView service desk 4.5 server_2 ... да так. зачем? просто для того что виртульная память ,используемая процессом, слишком велика. на картинке 1.4 Гб это для -Xmx1024M, если увеличить -Xmx то вырастет пропорционально. работаь с 1Гб или с 3Гб для JVM есть разница в производительности. это может сказаться при загузке апп. так вот если есть такое, то сервера следует разбить на 2 более мелких JVM. если нет "затыков" то и работай на одном. это и есть один пример. второй, ssp, web-console и web-api ипользуют апп, если загрузка велика, то следует разделить апп - один конкретно по пользователей, другой под нужды веба. если на это есть ресурсы у железа, да и память купить дешевле чем новый сервак, а к нему ещё и лицензию на винды. Join multiple server - это и есть кластер, отключать не надо. db и web у тебя в одном кластере, app вне кластера. db и web будут перекидовать пользователей в случае проблемы с сеткой и ли самим апп. Untitled.png (10.62 КБ) [ Скачать ] |
|
|
|
|
Странный глюкан, вешается сервер
|
1. неееее, зачем так радикально, совсем не факт что поле серверу станет лучше. в некоторых релизах явы бываю проблемы работы с памятью, во вторых большая виртуака ещё не факт что поможет( -Xmx - vistual size ). правильно когда есть соотношение между физической и виртуальной. вот дока http://java.sun.com/docs/hotspot/gc/ , хоть и старая но очень правильная и актуальня.
2. если они отдельные смысла в 1/3/4 нет --> 1/1/1. 3. на одном железе может быть поднято до 20 апп серверов( из док. НР). естественно если деф. порт 30999, то прибавь 1 получишь 31000 , читай внимательно "... это может быть и 4-й и 5-й....". надо деактивировать в HTTP, в ITP и SMTP оставить. в самом server_settings.xml важно изменить <PROPERTY NAME="METRICSPORT">6001</PROPERTY> на другой, иначе они(сервера) начнут ссорится из-за порта. кластеная система по НР-му "Join multiple server" - если один сервер падает, то клиент "замерзает" на некоторое время, потом сам переключается на др. рабочий сервер. пользователь это замечает только как торможение ("замерзает") клиента на 2-4 сек. Untitled.png (9.4 КБ) [ Скачать ] |
|
|
|
|
Странный глюкан, вешается сервер
|
вешается скорее всего из-за памяти: надо конкретно указать с какой памятью разрешено работать, например если на сервере 1.5 Гб, то -Xms768M -Xmx1024M подходит, 500м на операционку остальное яве.
веса: если это кластер и все апп работают с клиентами, то у всех должно стоять 3, т.е. каждый 3-й запрос мой, тогда распределение пойдёт равномерно по серверам. майл: чисто моё мнение,но повышающее стабильность в разы. майл это настолько важная вещь, что советую выделить его из кластера, закрыть доступ для клиента и оставить работать только на майл. память для такого сервера можно и урезать на минимун - для майла много ненадо. на всех других 25 порт закрыть. это может быть и 4-й и 5-й поднятый апп на том же железе на порту 31000 или ещё выше. |
|
|
|
|
Локализация, Importance
|
да вот как-то забыли
если надо исправь прямо в базе, таблица [ITSM_MAILPRIORITY_MAPPING] читается это по запросу: SEL ECT T1.mpm_mailpriority AS C0 ,T3.cdl_name AS C1 ,T1.mpm_oid AS C2 ,T1.mpm_pri_oid AS C3 ,T2.cod_ordering AS C4 ,T1.mpm_lockseq AS C5 FR OM (( itsm_mailpriority_mapping T1 LEFT OUTER JOIN itsm_codes T2 ON (T2.cod_oid = T1.mpm_pri_oid)) LEFT OUTER JOIN itsm_codes_locale T3 ON (T3.cdl_cod_oid = T2.cod_oid)) WHERE ((T3.cdl_lng_oid IS NULL OR T3.cdl_lng_oid = 1033 )) замени 1033 на свой , то приоритеты останутся. |
|
|
|
|