[Enhancement] InterruptedExceptions should not be ignored in the code.[ProducerImpl]
Search before asking
- [X] I had searched in the issues and found no similar issues.
Enhancement Request
located at:
eventmesh-storage-plugin/eventmesh-storage-rocketmq/src/main/java/org/apache/eventmesh/storage/rocketmq/producer/ProducerImpl.java line 85,99,113,140,
analysis and explanation:
InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the information that the thread was interrupted will be lost. Instead, InterruptedExceptions should either be rethrown - immediately or after cleaning up the method’s state - or the thread should be re-interrupted by calling Thread.interrupt() even if this is supposed to be a single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted - probably without finishing its task.
Similarly, the ThreadDeath exception should also be propagated. According to its JavaDoc:
If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.
Describe the solution you'd like
Just for reference, if you have better modifications, please correct me:

Remove this useless assignment; "msg" already holds the assigned value along all execution paths.

Are you willing to submit PR?
- [ ] Yes I am willing to submit a PR!
~~About removing supplySysProp(msg, cloudEvent), I have a different opinion. In method supplySysProp(msg, cloudEvent), the Message object seems to be set more value than before calling supplySysProp(msg, cloudEvent). I'm not sure the reason of deleting it~~.
Instead of removing supplySysProp(msg, cloudEvent), we remove the intermediate quantity msg. The method itself returns the value of this allocation.

Ooops. I misunderstood your meaning. Thanks.
Can I work on this issue? kindly assign it to me!
@j1803248734 You are welcome to submit a PR.
Completed, pull request submitted, please review.
I observed that the sendOneway, sendAsync, and reply methods did not return the sendResult object. Why does the send method need to return it?
I observed that the sendOneway, sendAsync, and reply methods did not return the sendResult object. Why does the send method need to return it?
@jevinjiang
Neither sendOneway nor sendAsync need to be concerned with the returned response, unlike the send method.
sendOneway和sendAsync都不需要关注返回的响应,和send方法不同。