[
https://issues.apache.org/jira/browse/DAFFODIL-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Beckerle resolved DAFFODIL-2216.
-------------------------------------
Fix Version/s: 3.0.0
Resolution: Fixed
Fixed in ed9e35c55e0ed75abab36e7d50217b937e6d4c1e
> thread-unsafe Logging trait usage
> ---------------------------------
>
> Key: DAFFODIL-2216
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2216
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 2.4.0
> Reporter: Mike Beckerle
> Assignee: Chia-Hung Lin
> Priority: Critical
> Labels: beginner, thread-safety
> Fix For: 3.0.0
>
>
> The logger functionality is provided by the Logging trait.
> This trait is mixed into, for example, the DataProcessor class.
> This trait has mutable members.
> This is a mistake. The PState/UState also mix in the Logging trait for use at
> runtime that way each thread (which requires a unique PState/UState) can have
> its own logger, own state for whether logging is on/off, own logging level,
> own I/O streams for writing to the log, etc.
> Currently the DataProcessor.doUnparse method is the only thing that calls
> DataProcessor.log, but it should be calling ustate.log instead.
> This change has API implications however, as the API for setting a logger and
> turning on logging needs to arrange for that information to be recorded on
> the PState/UState, but those objects aren't directly visible to the API.
> Since the logger is mutable state, we really don't want users to establish a
> single logger on the say, compiler or ProcessorFactory object instance, or
> even the DataProcessor instance, since that logger really should not get
> shared if users call parse multiple times on different threads. Rather, each
> parse/unparse call, which can be done on a separate thread, needs to be able
> to establish all its own mutable state.
> Unfortunately, right now the parse() call takes two arguments, the
> InputSourceDataInputStream, and the InfosetOutputter. I suppose the
> InputSourceDataInputStream, which cannot be shared, could have the logger
> methods mixed into it..... doesn't seem particularly clean.
> There are two different loggers: the compile-time logger, and the runtime
> logger(s) - the latter is plural since there can be distinct ones per each
> thread used for a parse or unparse call.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
