Unless you have a firm reason to think thread-contention is the cause, I don't think a thread-dump is the best place to start investigating why "few times in a day it takes 4 sec to process 5 messages.". There could be many,many causes to the problem, of which thread-contention is only one.
Firstly, I would identify those messages. Presumably the speed of messages is logged somewhere and if not, I would start with that. Can web-server access logs help identify these messages?
Once you have them, is there anything unique to those messages? If you access those messages yourself, are you able to replicate the slowness? Are they always at the same time of day/are they trying to access the same entities or perform the same actions? Are the messages sent by the same user?
If it's reproducible, you're job is half-done. You can now start using profiling tools to identify why it's taking so long.
Even if the slow messages are not reproducible and you cannot identify any distinguishing feature of the messages, at least you now know when it happened and can drill down more precisely.
Once you have the times, you can then start examining different causes at those times. A not-exhausive list would include:
- was there a full-garbage collection going on at that time?
- do other processes run on the application server at that time?
- if it accesses a database, was that under load at that time?
- are there any error messages in the logs for that time?
- was there any thread-contention at that time?
- are there any slow-running database queries at that time (for example, an Oracle AWR might give you this if you used Oracle)?
- were a lot of users, using the site at this time?
Identifying these require answers in their own rights, but Stackoverflow should have many. Regarding the thread-contention - was that thread analysis taken at the time the problem was occurring. Personally, I would like a thread-dump from that moment, to try and see which threads were were blocked by other threads.