Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shib-Dev] [IdPv3] Attribute Resolver Work

Subject: Shibboleth Developers

List archive

RE: [Shib-Dev] [IdPv3] Attribute Resolver Work


Chronological Thread 
  • From: "Bruc Liong" <>
  • To: <>, <>
  • Subject: RE: [Shib-Dev] [IdPv3] Attribute Resolver Work
  • Date: Thu, 27 May 2010 11:28:00 +1000

Title: RE: [Shib-Dev] [IdPv3] Attribute Resolver Work

>> And item that I thought about, be rejected, was:
>> - Making the attribute resolution process multi-threaded.  I rejected
>> this because it would add a significant amount of complexity to the
>> process and make it harder to track exactly what is going on.  In
>> addition the Servlet container is already allocating at least one thread
>> per-request. Additional pools of threads could result in resource
>> starvation or unexpected interaction with the container.

Another twist is to have an option on per attribute def whether it needs to be executed on its own thread, rather than making multi-threading for every attr resolution. This way, if that particular resolution is proven to be failing (for whatever reason), at least it doesn't risk/delay any other resolutions. If other attribute def (without this option) depends on an attribute def with this option, we can just let the parent attribute resolution wait for the child resolution to finish (making it looks like single-threaded). If supported, sharing common pool of threads (with controllable option to grow/shrink as needed) for all users would be more efficient to avoid starvation.

Agreed that this would add some complexity, but what would others do to the 'unpredictable' delay/failures of some attr resolutions these days, except keep waiting...

Bruc




Archive powered by MHonArc 2.6.16.

Top of Page