NativeSPClustering- shared shibd

[Vedran Bartonicek]

>>>But I don't generally hard code values like retry counts. If you file a
request, it can eventually get exposed as a configuration setting.

That wouldn't be necessary, thanks, I think I can live with the issue -
should happen very rarely - or our architecture can change to have httpd
and shibd
on the same machine.

The reason I ended up in this setup is that I am building a HA setup for
SP, which would lay in front of webserver cluster.
I was  intending to use floating IP with keepalived, and then have two SP
nodes in active-passive configuration. This works in prototype, but it's
not in production (yet).
Wandering if someone else tried something similar?

-Vedran










On 13 September 2016 at 21:17, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 9/13/16, 12:33 PM, "users on behalf of Vedran Bartonicek" <
> users-bounces at shibboleth.net on behalf of vbartoni at gmail.com> wrote:
>
> >    Thanks for the clarification. In case I manage to find a root
> cause,will publish to
> > this thread.
>
> I looked at the code to refresh my memory, and indeed what it does is use
> a connection from the pool and if the send() call fails, it does a single
> retry by fetching another from the pool.
>
> I suppose it's true that if there were that many bad connections in the
> pool, it would be visible, and I think in practice there just usually
> aren't because the pool count tends to be very small.
>
> I think there are more here because you're doing what should not be done,
> using a remote service. The system is incapable of performing at any scale
> that way, so there are all sorts of reasons it's not workable, and this is
> just one more.
>
> But I don't generally hard code values like retry counts. If you file a
> request, it can eventually get exposed as a configuration setting.
>
> -- Scott
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160914/6d32660a/attachment-0001.html>