And now what?
time to read 1 min | 48 words
It looks like the entire MSMQ .NET stack is riddled with threading bugs. At least if you think about using the async methods such as BeginPeek.
Nasty!
Ayende @ Rahien
Ayende @ Rahien
Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by email or phone:
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by email or phone:
+972 52-548-6969
FUTURE POSTS
- Giving Demeter PTSD - 7 hours from now
- PR Review: Code has cost, justify it - about one day from now
- PR Review: Beware the things you can’t see - 4 days from now
- The right thing and what the user expect to happen are completely unrelated - 5 days from now
- PR Review: It’s the error handling, again - 6 days from now
There are posts all the way to Oct 25, 2017
RECENT SERIES
-
PR Review
(7):
10 Aug 2017 - Errors, errors and more errors -
RavenDB 4.0
(15):
13 Oct 2017 - Interlocked distributed operations -
re
(21):
10 Oct 2017 - Entity Framework Core performance tuning–Part III -
RavenDB 4.0 Unsung Heroes
(5):
05 Oct 2017 - The design of the security error flow -
Writing SSL Proxy
(2):
27 Sep 2017 - Part II, delegating authentication
RECENT COMMENTS
-
By Oren Eini on Cost centers, revenue centers and politics in a cross organization world
-
By Pop Catalin on Cost centers, revenue centers and politics in a cross organization world
-
By Oren Eini on Complex Linq queries in RavenDB 4.0
-
By Derek on Complex Linq queries in RavenDB 4.0
-
By Jason He on Complex Linq queries in RavenDB 4.0
Syndication
| Main feed |
|
| Comments feed | |
Comments
have you ever thought about joining Microsoft as a tester? :)
@J - haha - second that!
are you using PeekCompleted? i use this pattern for peeks and reads and it may be why i haven't encountered the set of problems you have.
msdn.microsoft.com/.../...queue.peekcompleted.aspx
shawn,
No, I am using the delegate passed to the async method
If you are going to make a statement like this, then shouldn't you at least show the situation under which the error occurred? From what you have shown us, it is hard to ascertain if your claims are indeed true, or you are doing something wrong and just blaming it on the .net MSMQ apis.
Justin,
Null Reference is almost always a bug.
In this case, I am access the AppSpecific property on a message, and it throws this error.
This is caused because of a bug in certain scenarios in which even though the queue is set to accept AppSpecific, it doesn't
An assert failing in production code means that some invariant somewhere is no longer true, and that the author of the code considered such a situation a bug.
Therefore Oren's statement is valid.
@Ayende Thanks for the clarification. I didn't doubt that it was a bug on their part, I just like seeing what caused them so that I know in the future where the dragons may be.
No, that is actually not an assert that is failing.
The assert is in my code.
The problem is that NRE.
choke JMS.... :-P
@Mr Anonymous
Hey no fair - you stole my handle.
Though context is and always would be helpful (or at least more informative ;) ) I'm with Oren on this one. NRE == bug.
You should stop relying in ObjectDisposedException and not touch an object after disposing it. Think of ObjectDisposedException as a debuging aide.
Comment preview