Shibboleth Developer's Meeting, 2020-06-05

Brent

Daniel

Henri

Ian

• Thread safety is hard:
  • Arises through 

    Jira Legacy
    server Shibboleth JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 180d847f-bce4-36b2-9964-771bff586829 key MDA-242

  • Things in both the MDA and our other code claim to be @ThreadSafe when they are, strictly, insufficiently synchronized.
    • There seems to be a widespread pattern where setters are synchronized while getters are not. As this is dominant in older MDA code, I think it may come from Chad originally.
      • From Gaetz's book: It is a common mistake to assume that synchronization needs to be used only when writing to shared variables; this is simply not true.
      • You need to synchronize both setters and getters to get the visibility guarantees I think you want.
      • If you're using something else to get those guarantees, then you are probably @ThreadSafeAfterInit and not @ThreadSafe and you don't need either setters or getters to be synchronized.
      • Simple example would be AbstractInitializableComponent, which just has getters but none are synchronized. (There is synchronization on the effective setters initialize and destroy).
      • Or, MessageLifetimeSecurityHandler where setMessageLifetime is synchronized but getMessageLifetime is not.
    • Sometimes code just refers to the field instead of the getter anyway.
  • We probably get away with this because:
    • roperties aren't set after initialization.
    • Everything is initialized on one thread and then other threads are created to do the work. As long as these are explicitly started later or initiated by classes such as Executor, visibility is guaranteed by the library (not the language).
    • Real processors don't buffer writes forever, anyway.
  • I can't find anywhere we have documented our approach to writing concurrent beans.
  • I think there are two consistent positions:
  • Objects are @ThreadSafe and get there by either:
    • If having constructor arguments, having only final fields.
    • If an InitializableComponent, having every setter and getter synchronized and never referring to fields except through the getter.
    • Some combination of the above and other techniques to make the object fully thread-safe.
  Objects are @ThreadSafeAfterInit (obviously only applies to InitializableComponent )Setters and getters need not be synchronized. User constraint that creation of the object and all steps up to and including initialize must be performed on the same thread before the object becomes visible to another threadFull discussion there.
  • TL;DR: we're probably OK, mostly, but we might want to document some assumptions and possibly tweak a couple of base classes in java-support to future-proof them.

Marvin

Rod

Scott

Tom

Other