gstein commented on PR #9: URL: https://github.com/apache/serf/pull/9#issuecomment-3027019227
If a context is running 4 connections to a server, and they are sharing an SSL context, then this callback attached to the shared context cannot identify the connection, can it? (I kinda recall reading that somewhere) I'm also thinking that this "error callback" being specialized only to SSL is missing a review of how to do this properly for serf in general. And yes, I **DO** want a general design, rather than tack on a "single solution today" and "generalize later". To generalize it (likely beyond scope of desire of this PR), I'd seek some kind of baton/identifier of "what request is this error attached to?" ... I believe the request is the "unit of work" and any error would be associated with that. Could be a response, but that is in response to a request. ... Hmm. I guess one could also associate an error with a connection, or a shared context. eg. timed out a connection setup before we even tried to deliver a request. In short, I do not think it appropriate to apply a hack to fix one case, when we don't have a conceptual design (even if not fully-implemented) for a serf-wide sophisticated error handling design. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@serf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
