[
https://issues.apache.org/jira/browse/ROCKETMQ-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaskey Lam updated ROCKETMQ-97:
-------------------------------
Description:
For sendAsync, when excpetion occurs, the developer will have nothing to
distiguish what kind of exception it is unless read the remark or stacktrace.
Actually, for some broker problems, say service_not_availble or system_error,
the devs should do some special actions.
But for now, with no response code , we can't distinguish them.
Even more, for some situation, the queue sent to is needed , so if possible,
there should be an ext fields where collect as many message as possible to let
developer to descide their callback behavior.
was:
For sendAsync, when excpetion occurs, the developer will have nothing to
distiguish what kind of exception it is unless read the remark or stacktrace.
Actually, for some broker problems, say service_not_availble or system_error,
the devs should do some special actions.
But for now, with no response code , we can't distinguish them, even, for some
situation, the queue sent to is even needed , if possible there should be a
ext fields where collect as many message as possible to let developer to
descide their callback behavior.
> SendCallback should bring response code and extMessags in OnException
> ---------------------------------------------------------------------
>
> Key: ROCKETMQ-97
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-97
> Project: Apache RocketMQ
> Issue Type: Improvement
> Components: rocketmq-client
> Reporter: Jaskey Lam
> Assignee: Xiaorui Wang
>
> For sendAsync, when excpetion occurs, the developer will have nothing to
> distiguish what kind of exception it is unless read the remark or stacktrace.
> Actually, for some broker problems, say service_not_availble or system_error,
> the devs should do some special actions.
> But for now, with no response code , we can't distinguish them.
> Even more, for some situation, the queue sent to is needed , so if
> possible, there should be an ext fields where collect as many message as
> possible to let developer to descide their callback behavior.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
