Threading issues - Best way to debug
Hey everyone... I have a small server program that I wrote in Java. Its module based where each thread that is created runs through a list of modules and returns the output. It works just fine and I am doing a little stress test using Siege. I set it up running 50 concurrent users with no delay and take millions of requests with no errors at all.
However, when I move it up to 125 concurrent users, I start getting NullPointerExceptions on a fairly routine basis (inside of one of the modules). The server is still running with no issues, just with that many users it appears to have a bug.
I was wondering what the best way figure out why this would be happening. Or is this kind of thing to be expected and I should just implement some method of throttling for the threads. I plan to do that eventually, just trying to get the bugs out first.
Thanks in advance!
# 1
Fix the null pointer exceptions. Then come back here if you have concurrency issues.
A null pointer is a programming error. There is no point thinking about testing concurrency issues if you have known errors.
# 2
> Fix the null pointer exceptions. Then come back here
> if you have concurrency issues.
>
> A null pointer is a programming error. There is no
> point thinking about testing concurrency issues if
> you have known errors.
So you don't think it's possible that concurrency issues are causing this NullPointer? I disagree, I think if you fix the concurrency issue you might solve the NullPointer issue. I could be wrong and I haven't seen the code, but not sure why you think they are separate.
# 3
Well, here is my reasoning as to why I think its related th concurrency.
The logic works just fine (with no exceptions) on single requests and concurrent requests up to about 50 users. When I change the concurrent requests to about 125 is when it starts throwing exceptions.
Now, the thing is that it will throw the exceptions, but if I stop the bombardment and try another single request or a smaller amount of concurrent connections, goes back to working just fine.
As I said before, I do plan on implementing some kind of throttling but I would rather investigate this issue a bit more before applying a permanent fix.
Thanks
# 4
I think you are seeing the NPE concurrent scenario because of the assumptions you code is making about how JVM should behave. You code may be making assumption of "happens-before" pattern which may seem valid when you look at the code, but in fact are not.
Take a look at this presentation that outlines the Java Memory model and defines the contract between concurrent programs and JVM.
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1630&yr=2006&track=coreplatform
Throttling the method is a bad idea (and a cop out). How would you arrive at the optimal number threads that can safely access your program ? Will your code be portable when it is deployed on a computer with different computing power than what you are testing on ?
Hope this helps.
-Prashant
# 5
Thanks for the reply Prashant. I will check out the memory model and see where my logic is going wrong.
However, I do want to question the throttling deal. Why wouldn't I want to make that a user configurable option? Seems like a way to deal with DOS attacks and keeps control over the process (so other potential apps on the system can also have their own kernel time).
While I agree its a bad idea as a fix to this issue, I still think its a good idea in the long run as a general option. What do you (or anyone else) think?
