Above tracing doesn't only mean that assign action is taking time, it could also mean that there is starvation of kernel thread (socket muxer threads) in weblogic. This could happen under high load. When request pipeline completes in route, it register a muxer thread for callback and copies context variable there and then releases original request thread. If under high load, these socket muxer threads are not available then there could be unnecessary delay between context variable exchange as looks high possibility in your case.
What we need to do is separate thread pool for muxer threads and osb req-resp pipeline threads. You need to:
- Create custom workmanager and assign it to proxy and business service using dispatch policy. Defining parameters for work manager is tricky part and involves study of load and thread dump etc. I always get confused defining best tuned workmanager.
- Or simply, its time to increase your hardware capacity. If your organization is planning further scalability in future then it could be time.
Above is the direction and solution which I will recommend. As far as assign action is concerned, nothing looks suspicious on that. Still you can try "$body/*". And also put a log statement after assign and before route. It will help verifying if it is issue of assign or thread starvation.
Hope this helps.
As Ankit mentioned, I doubt the issue is with the assign action. The above assign actions should not cause such a delay. As the performance degradation is intermittent and occurs only during peak load, it is less likely due to assign action. It would be ideal to take few thread dumps during heavy load and analyze it.
Also, did you collect the statistics before and after the assign operations? The trace message tells it is collected after sending the outbound message.