Click here to Skip to main content
15,900,511 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
Questionmultiple inheritance Pin
ron0123427-Feb-13 21:59
ron0123427-Feb-13 21:59 
AnswerRe: multiple inheritance Pin
Bernhard Hiller27-Feb-13 23:24
Bernhard Hiller27-Feb-13 23:24 
AnswerRe: multiple inheritance Pin
jschell28-Feb-13 10:12
jschell28-Feb-13 10:12 
AnswerRe: multiple inheritance Pin
GuyThiebaut9-Mar-13 8:14
professionalGuyThiebaut9-Mar-13 8:14 
GeneralRe: multiple inheritance Pin
jschell10-Mar-13 6:22
jschell10-Mar-13 6:22 
GeneralRe: multiple inheritance Pin
dusty_dex10-Mar-13 6:51
dusty_dex10-Mar-13 6:51 
QuestionData transfer Pin
benkazy101422-Feb-13 20:46
benkazy101422-Feb-13 20:46 
AnswerRe: Data transfer Pin
Richard MacCutchan22-Feb-13 23:06
mveRichard MacCutchan22-Feb-13 23:06 
AnswerRe: Data transfer Pin
Sandeep Mewara23-Feb-13 2:57
mveSandeep Mewara23-Feb-13 2:57 
QuestionData transfer Pin
benkazy101422-Feb-13 20:41
benkazy101422-Feb-13 20:41 
QuestionMemory management for object growing in size Pin
Dev S21-Feb-13 5:47
Dev S21-Feb-13 5:47 
AnswerRe: Memory management for object growing in size Pin
Richard MacCutchan21-Feb-13 6:35
mveRichard MacCutchan21-Feb-13 6:35 
AnswerRe: Memory management for object growing in size Pin
Bernhard Hiller27-Feb-13 23:27
Bernhard Hiller27-Feb-13 23:27 
Questionnavigation Pin
Nani Maneesh20-Feb-13 7:14
Nani Maneesh20-Feb-13 7:14 
AnswerRe: navigation Pin
jschell20-Feb-13 8:16
jschell20-Feb-13 8:16 
AnswerRe: navigation Pin
Sandeep Mewara20-Feb-13 17:08
mveSandeep Mewara20-Feb-13 17:08 
QuestionDDD and vb.net Pin
alex.barylski17-Feb-13 7:33
alex.barylski17-Feb-13 7:33 
QuestionAdvice - WCF/MSMQ or Async TCP Pin
Ger Hayden14-Feb-13 9:14
Ger Hayden14-Feb-13 9:14 
AnswerRe: Advice - WCF/MSMQ or Async TCP Pin
jschell14-Feb-13 12:25
jschell14-Feb-13 12:25 
Some considerations which might or might not matter.

I am rather certain that you can't use WCF, MSMQ and MSMQ Transactions. You can investigate yourself but I believe there is a fundamental problem in terms of receiving them. Basically they can be sent ok (with a transaction), but when receiving them there is no assurance that the transaction is preserved. (I can't remember how I came to this conclusion.)

MSMQ has a hard 4 meg byte limit per message. Between overhead and unicode (not optional) that can reduce the maximum message sized to less than 2 meg (bytes.) Microsoft technical docs state they have no intention of changing this limit.

Despite claims to the contrary WCF/MSMQ does not support a streaming operation. So the message must always be less than 2 meg.

MSMQ uses magic routing which is great when it works (when you get all the ports/permissions right) but is extremely difficult to figure out otherwise. And because of that messages can take a long time to arrive at the target, for example hours.

MSMQ at least on OSes before 2008 (and maybe that too) uses by default a single file with a 2 gig limit for persistence. MSMQ will crash if that file fills. And there is no way to monitor problems via the MSMQ API (maybe there is something in WMI.)

Most of the standard MSMQ 'queues' use Active Directory. If Active Directory has problems then MSMQ will have problems. If you use options to exclude Active Directory then you CANNOT insure transactions are in use. See next note.

If one queue uses transactions and the other end doesn't, messages just disappear.

MSMQ failures can result in MSMQ exceptions which have a enum which indicates the type of error. The problem however is that API can end up returning a value, via the enum api, which is not a enum. Basically violating the contract of the method.

MSMQ queue permissions and application permissions must match. Which would seem obvious. However if they don't match then it returns non-helpful errors. Such as telling you that the queue doesn't exist (even though it does.)

MSMQ is supposed to support multiple clients consuming from a single queue. However someone I know (but not me) ran a test that suggested performance was significantly degraded in such a scenario when transactions were in use. Developing around this is complicated.

I can state that I built message streaming using chunking to break a larger (bigger than 4 meg) into pieces. It was extremely difficult. Especially since I was attempting to support multiple clients (see above limitation)

MSMQ is tied to the OS. This of course means that if you want to upgrade from, say, MSMQ 3.0 to 4.0, then you must upgrade the OS.
GeneralRe: Advice - WCF/MSMQ or Async TCP Pin
Ger Hayden14-Feb-13 22:40
Ger Hayden14-Feb-13 22:40 
AnswerRe: Advice - WCF/MSMQ or Async TCP Pin
Raul Iloc24-Feb-13 2:01
Raul Iloc24-Feb-13 2:01 
AnswerRe: Advice - WCF/MSMQ or Async TCP Pin
Marc Koutzarov29-Aug-14 12:10
professionalMarc Koutzarov29-Aug-14 12:10 
GeneralRe: Advice - WCF/MSMQ or Async TCP Pin
Ger Hayden29-Aug-14 23:32
Ger Hayden29-Aug-14 23:32 
GeneralRe: Advice - WCF/MSMQ or Async TCP Pin
Ger Hayden9-Nov-14 2:41
Ger Hayden9-Nov-14 2:41 
Questionrich text editor Pin
Danielos_s2330-Jan-13 10:03
Danielos_s2330-Jan-13 10:03 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.