[
https://issues.apache.org/jira/browse/IVY-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-639.
------------------------------
Resolution: Fixed
I've just checked in a fix for this problem, along with a simple test case. I
had to make several modifications to the way Message is implemented and
handled, and since we haven't many unit test for this, I hope I haven't
introduced bugs...
The major change in Message implementation is that it now delegates all the
work (including problems summary and all the stuff) to a MessageLogger
implementation. MessageImpl has been removed in favor of MessageLogger, with an
AbstractMessageLogger class useful to easily implement a MessageLogger from
what was previously an implementation of MessageImpl. Now the Message class can
be seen as a simple static facade to the current (IvyContext) MessageLogger.
The MessageLogger returned is actually the MessageLoggerEngine associated with
the current Ivy instance. If there is no such instance, a default one is
created (as it used to be), which in turns creates a MessageLoggerEngine which
has a default MessageLogger set according to the
Message.getDefaultMessageLogger. So the default MessageLogger can be configured
before creating the Ivy instance by calling
Message.setDefaultMessageLogger(MessageLogger), or after the Ivy instance
creation by Ivy#getLogger().setDefaultMessageLogger(MessageLogger).
The MessageLoggerEngine is actually a stack of MessageLogger, with a default
MessageLogger used when the stack is empty. This allows Ivy Ant tasks to push a
different logger associated with the task, and pop it when finished, with
problems (errors and warnings) still being collected in the engine itself.
For the IvyContext itself, a Stack of context is attached to the current thread
instead of a single context, and the pushing and poping of context is done in
all public methods of the Ivy class in which that makes sense. To use engines
directly, you should use the Ivy#execute(IvyCallback) methods, which is
documented in the javadoc.
Feel free to report any problem related to this change, as I'm not fully
confident with its stability yet.
> Bad IvyContext scope causing memory leak and bad handling of subproject builds
> ------------------------------------------------------------------------------
>
> Key: IVY-639
> URL: https://issues.apache.org/jira/browse/IVY-639
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.0-alpha-2
> Reporter: Xavier Hanin
> Assignee: Xavier Hanin
> Priority: Critical
> Fix For: 2.0.0-beta-1
>
>
> Ivy relies on a mechanism of IvyContext to access to some contextual
> information without passing them throughout all methods parameters.
> The problem is that only one context is attached to the current thread, and
> it is never cleaned. This leads to two kind of problems:
> - memory leak, which is the root cause of an issue reported in Ant:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=42742
> - bad management of subprojects, in which the parent IvyContext is losed when
> the subproject starts. Details about this have been reported by Peter Reilly:
> http://www.nabble.com/use-of-IvyContext-tf4472787.html#a12752879
> The solution to this problem is to use a stack of IvyContext rather than a
> single one, and push the context on each Ivy method call, and pop it at the
> end.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
