Please clarify: is this a blocker for devstudio 10.0.0.GA? Or something to
pick up in a later sprint / release?
Given we've slipped respin-a to Monday, and still have to rebrand
everything, we probably have time to contain a small TP change like this.
IFF it's a blocker.
On Fri, Jun 10, 2016 at 2:35 PM, Jeff Johnston <jjohnstn(a)redhat.com> wrote:
I have just made a build available with the patch in:
http:/download.eclipse.org/linuxtools/update-neon-docker-rc4a
-- Jeff J.
----- Original Message -----
> Moving to jbosstools-dev.
>
> OK. This memory leak seems to be bad. Please continue to work on proper
> bug fix and update for the Linux/Docker Tools for Neon but I'm afraid we
> don't have time to change anything in our Target Platform for devstudio
> 10 GA / JBoss Tools 4.4.0.Final at this point.
>
> Thanks.
>
> On 06/10/2016 12:56 PM, Jeff Johnston wrote:
> > Should be Neon only as status icons were added for Neon M1 milestone.
> > There
> > may be other image leaks in Mars, but they are minor and no errors have
> > shown
> > in our testing or customer usage.
> >
> > -- Jeff J.
> >
> > ----- Original Message -----
> >> Is this bug in Neon branch only? What about Mars releases?
> >>
> >>
> >> On 06/10/2016 12:38 PM, Jeff Johnston wrote:
> >>> It appears that the issue I found has been around since Aug 2015
(Neon
> >>> M1).
> >>> I have a fix
> >>> and there appears to be another possible leak in the
DockerExplorerView
> >>> which I
> >>> am pushing a fix for currently.
> >>>
> >>> I noticed the memory leak the other day and during my testing I saw
that
> >>> images
> >>> were being left behind to the point that the Eclipse MAT tool took
notice
> >>> over a
> >>> short period and flagged it as a suspected memory leak. Docker
> >>> Containers
> >>> get refreshed every 15 seconds so Views
> >>> that show them (Docker Containers View and Docker Explorer View)
that use
> >>> icons need
> >>> to dispose of them properly. For the Docker Containers View, all
> >>> containers were being
> >>> given a new image each refresh period. The Explorer View isn't
much
of a
> >>> problem because
> >>> it is node-based and doesn't always show the full list of
Containers. A
> >>> short list of Containers
> >>> will slow down the leak as will closing the View.
> >>>
> >>> My intention was to do a quick rebuild of the stable-5.0 branch and
save
> >>> it
> >>> as RC4a repo. If desired,
> >>> I can do a point release, but this requires more changes to all
features
> >>> and pom files to renumber
> >>> them. Let me know if a point release is required.
> >>>
> >>> I will continue with the task of building an RC4a repo that will be
saved
> >>> in the Linux Tools download
> >>> area. Neon users will have to use the updates-nightly-neon repo
which
> >>> will
> >>> have
> >>> the fix (same git branch is used to create the RC4a repo).
> >>>
> >>> -- Jeff J.
> >>>
> >>> ----- Original Message -----
> >>>> When did it happen? How long do you have it in Docker Tools.
> >>>>
> >>>> Have you already fixed it? Released the updated 2.0.1?
> >>>>
> >>>> On 06/10/2016 11:19 AM, Jeff Johnston wrote:
> >>>>> This issue was introduced with a change to adding status icons
in
the
> >>>>> Containers View. It wasn't noticed because it requires a
long
time to
> >>>>> show (small image icons not being disposed of).
> >>>>>
> >>>>> -- Jeff J.
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> We will conceder to include any updated in respin-b
besides
branding
> >>>>>> only if we have to fix some very bad issues. Real blocker.
> >>>>>> Is this issue is old or some new regression?
> >>>>>>
> >>>>>> On 06/10/2016 10:57 AM, Xavier Coulon wrote:
> >>>>>>> From my understanding, Jeff noticed the issue after
letting
> >>>>>>> Eclipse
> >>>>>>> run
> >>>>>>> all night long, but I don't remember if Eclipse
was then
unusable
> >>>>>>> or
> >>>>>>> crashed.
> >>>>>>> Anyway, it could be serious enough it users have the
Docker
tooling
> >>>>>>> views
> >>>>>>> open in their workspace.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Xavier
> >>>>>>>> On 10 Jun 2016, at 12:37, Alexey Kazakov
<alkazako(a)redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> How bad is that leak?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Jun 10, 2016, at 4:33 AM, Xavier Coulon
<xcoulon(a)redhat.com
>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Fred, Alexey,
> >>>>>>>>>
> >>>>>>>>> Jeff J. found a memory leak in the Docker
tooling. It's too
late
> >>>>>>>>> for
> >>>>>>>>> Neon.0 RC4/Final, but he proposes that we cut a
Linux Tools
5.0.1 /
> >>>>>>>>> Docker Tooling 2.0.1 to address this specific
issue.
> >>>>>>>>> Is this something that can be included in the
upcoming
"respin-b"
> >>>>>>>>> build
> >>>>>>>>> along with the branding updates ? I understand
that Alexey
> >>>>>>>>> initially
> >>>>>>>>> said that this ultimate build would not include
any other bug
fix,
> >>>>>>>>> but
> >>>>>>>>> nonetheless, I'm asking the question ;-)
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> /Xavier
> >>>>>>>>>
> >>>>>>>>>> Hi Xavier,
> >>>>>>>>>>
> >>>>>>>>>> Jeff here. I found a memory leak in the
Docker Containers
View.
> >>>>>>>>>> I
> >>>>>>>>>> believe it is fixed with my gerrit patch.
If JBoss wants, I
can
> >>>>>>>>>> create
> >>>>>>>>>> a
> >>>>>>>>>> special repo for them to use to remove this
bug. The fix is
too
> >>>>>>>>>> late
> >>>>>>>>>> for
> >>>>>>>>>> Neon, but we can cut a point release if
necessary or wait
until
> >>>>>>>>>> 5.1
> >>>>>>>>>> and
> >>>>>>>>>> fix it in the updates-nightly-neon.
> >>>>>>>>>>
> >>>>>>>>>> The problem was with the images used for
status in the Table.
> >>>>>>>>>> They
> >>>>>>>>>> were
> >>>>>>>>>> constantly being created via createImage()
but never stored
any
> >>>>>>>>>> where
> >>>>>>>>>> and
> >>>>>>>>>> never disposed. I simply created 3 images
for status and
return
> >>>>>>>>>> one
> >>>>>>>>>> of
> >>>>>>>>>> 3
> >>>>>>>>>> for each table entry, then dispose of them
in the Containers
View
> >>>>>>>>>> dispose
> >>>>>>>>>> method.
> >>>>>>>>>>
> >>>>>>>>>> -- Jeff J.
> >>
>
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio