...
Before uPortal 2.5.1, StatsRecorder used portal.properties properties to configure which IStatsRecorder methods, if any, it would propogate. It also used portal.properties to configure a thread pool and would fire a thread to execute actual event propogation. This allows, for instance, the statistics recording for channel rendering to happen outside of the thread actually trying to render channels and to manage channel rendering. Quite possibly necessary for recording channel rendering. Quite possibly overkill for recording user login, which is already an expensive operation anyway to such adding some simple stats recording won't make a noticable difference.
Whether threads need to be fired can depend upon how expensive it is to do what you're trying to do with the stats. Logging probably doesn't need new threads. Writing to a slow backing database or calling out to a remote web service might.
In uPortal 2.5.1, the thread firing behavior moved out of StatsRecorder and into a particular IStatsRecorder wrapper implementation, ThreadFiringStatsRecorder.
...