minfrin commented on PR #9: URL: https://github.com/apache/serf/pull/9#issuecomment-3027170728
> 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) This is a general limitation of serf that exists already. When serf fails, it returns apr_status_t. What connection that apr_status_t belongs to, serf doesn't tell you. > 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. Right now, I want to contact a vendor and say "I get this message, please help", and not receive from the vendor pages and pages of "it could be this, or it could be that, or maybe this, or maybe that", and then eventually find out that it was actually none of the above, and all of this occurred for the want of an actual error message. Our community is orders of magnitude more important than the code. I entirely get the desire to attach this error to "a unit of work", your choices for a unit of work in this code consist of just one structure, serf_ssl_context_t, and that is it. https://github.com/apache/serf/blob/trunk/buckets/ssl_buckets.c#L136C8-L136C26 The parent structure for serf_ssl_context_t is serf_config_t. There are no other "units of work" today, serf just doesn't work like that. Obviously one can go off on a tangent and rewrite serf to invent new "units of work" and then use this as a basis for a different error handling mechanism. This is however hugely disrespectful to the community, who need proper error messages today, and who cannot be held to ransom until someone is forced to do unrelated work. We must provide error handling for the serf in front of us today, not some future serf that might exist in the future but doesn't. -- 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
