Den tors 11 dec. 2025 kl 19:43 skrev Branko Čibej <[email protected]>:
> On 11. 12. 25 19:59, Daniel Sahlberg wrote:
> > Hi,
> >
> > Prompted by Evgeny's suggestion to move forward with releasing Subversion
> > 1.15.0[1], I'd like to suggest getting a new minor release of Serf out of
> > the door as well - preferrably first!
> >
> > There are a few features in Subversion that depend on recent development
> in
> > Serf (for example the error reporting) and it would be nice to have it
> > released together.
> >
> > Brane has made a summary in Jira, see SERF-208[2], open points copied
> below:
> > * Generalized error callbacks, discussed in [3]. From what I can see we
> > have an error callback mechanism that works for SSL errors. There is also
> > code in Subversion to support this. We need to decide if [a] We are happy
> > with the current situation, or [b] Can someone step up to improve it.
> > Personally, I'm leaning towards [a].
>
> I'm not happy with the current custom callback just for SSL errors. I'd
> be -0.9 to release it as a public API. I sort of dropped the ball .
>
In the previous thread, I proposed a patch which replaced the callback with
a more generic serf_error_cb_t, with an addtiional error_type parameter.
Basically:
[[[
-typedef apr_status_t (*serf_ssl_error_cb_t)(
+typedef apr_status_t (*serf_error_cb_t)(
+ serf_error_type_t error_type,
void *baton,
apr_status_t status,
const char *message);
]]]
I did NOT implement this anywhere else apart from the ssl code but it
should be easy enough to add to other parts of Serf as well.
WDYT?
> * Issue SERF-195, which is a substantial rewrite of the request queues.
> The
> > code is in a separate branch SERF-195. The code looks good to me but I
> > haven't analyzed in detail. It should be possible to merge to trunk.
>
> The patch works, in the sense that it causes no regressions, but I
> haven't been able to reproduce the reported issue. It's also makes the
> code slightly more readable, but I couldn't find the mentioned race
> condition during review, it looks like just a refactoring of the
> original code.
>
> I think we need another pair of eyes to do a careful review of the
> branch changes.
>
I'll try to reproduce the initial issue and see if I can figure out what
goes wrong. Do you have any ideas where I should start? I assume a
multithreaded client (with multiple connections) would be needed?
>
> > * Issue SERF-209, concerning intermitent test suite failures under
> MacOS. I
> > would suggest to leave this aside for later.
>
> Yes, it's not critical. Might be something in the test code itself,
> i.e., not related to serf proper.
>
Ack!
Cheers,
Daniel
>
> > Can we get these decided/merged and roll a release? I think it would be
> > good to do this in trunk before branching.
> >
> > Kind regards,
> > Daniel
> >
> >
> >
> >
> > [1]https://lists.apache.org/thread/x0s1c8jolql5hdkq40jm3jfnpm6wjp9s
> > [2]https://issues.apache.org/jira/browse/SERF-208
> > [3]https://lists.apache.org/thread/7khn697o2srmg8wvqy4t3xyxq4cr8v8v
> >
>
