|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
Один клоун по имени Инго Раммер написал в своей книжке что ремотинг ивентсы работают очень плохо не надежены и пр. поэтому наш старший умник (а он любитель этого раммера - я просто думаю что он педик и ему раммера фотка нравится на книжке) решил что надо делать нотификацию клиента через мсмкью. у кого какие идеи на этот счет? (я имею ввиду не про педиков - а высказаться кому интересно по поводу сравнения двух решений) для информации - клиенты наши коннектятся к винсервису которые хостит ремотинговые объекты которые раздают данные из базы. вроде бы сервис этот будет всегда один единственный. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.02.2004, 20:11 |
|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
да, иногда калбэки не проходят, если сервак за фаерволами стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2004, 03:03 |
|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
MSMQ - это служба для доставки сообщений. Т.е. например как MSSQL - это сервер БД - так эта штука занята тем что осуществялет гарантированную доставки сообщения - т.е. это достаточно сложные службы и они всегда присутвовали на серверных платформах (т.е. аналоги есть и на Unix и на мэйнфреймах и т.д.) Так вот - по сравнению с ней - всякие другие способы доставки сообщений - менее надежны :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2004, 10:06 |
|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
ясно. спасибо за ответы. еще вопрос если кто знает - не могу понять пока одну вещь - как определять адрес клиента. т.е. в моем приложении клиенты но для мсмкью это будет сервер т.к. сервер приложения будет отправлять сообщения клиенту и получается что клиент - это мсмкьюшный сервер т.к. он должен слушать очередь.. везде написано что нужно указывать URI получателя для отправки мсмкью сообщения. клиентов по определению может быть навалом в том числе и мобильные всякие и т.д. получается вести самому как то базу URI клиентов и перегружать конфиг ремотинга на сервере каждый раз как кто то подключился? это кажется полный маразм. есть что то более гибкое? бродкастинг какой нить? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2004, 13:00 |
|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
нет, бесполезное занятие, многие клиенты через прокси лезут и не имеют своего адреса. в своих приложениях у нас реализована служба, которая с заданным интервалом забирает накопившиеся мессаги с сервака. сервак, разумеется, вызывает события только ассинхронно. посмотри кустом-реализации каналов ремоутинга, вполне можно реализовать канал методом POP. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.02.2004, 16:15 |
|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
дык у нас и так кустом синки стоят на ремотинге. дело не в том что лучше а в том как босс сказал как лучше :) msmq наша новая пестня :)... вобщем получается длинная лабуда. типа забирать peek асинхронно всеми клиентами а потом очищать по тайм ауту или что то в этом роде. вобщем я пока не разобрался. ставить мсмкьюшные триггеры мне кажется не более надежная вещь чем ивенты в ремотинге и ивент на приход мскьшного сообщения если очередь на другом компе наверное тоже имеет свои проблемы. не хочется обнаружить эти проблемы по концовке... вобщем пока я не принял решения что с этим делать.... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.02.2004, 12:27 |
|
MSMQ via Remoting Events
|
|||
---|---|---|---|
#18+
че то у меня вообще нифига не работает :( Код: plaintext 1.
если имя очереди задать неправльным - выдает ошибку. т.е. что то оно там делает. но сенд не происходит. сообщение в очереди не появляется. я ради интереса поставил deny send в секюрити этой очереди - и никакой реакции. такое впечталение что очередь оно то открывает а писать туда ничего не пишет. все сделал поумолчанию, перечитал 8 раз примеры из мсдн. ниче не могу понять.. как продолжать если я простое синхронное сообщение не могу послать?.. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.02.2004, 13:37 |
|
|
start [/forum/topic.php?fid=19&msg=32409012&tid=1398159]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
154ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 234ms |
total: | 485ms |
0 / 0 |