[teiid-designer-dev] Preview VDB Cleanup
Ramesh Reddy
rareddy at redhat.com
Fri Jan 28 09:40:18 EST 2011
Except (1), I would not consider any one. Also when it cleaning I would
clean all the resources with that workstation id, not just the one you
been keeping track.
(2) is bad because you did not ask the user if he wants to create
preview, why askiing them if they want to delete?
(3) is would be bad. The assumption to keep the previews when the
designer is not running is bad IMO. There is no benefit in doing this.
(4) is not an option, we have an issue that there are orphan preview
VDBs and data sources that never get cleaned up.
Ramesh..
On Fri, 2011-01-28 at 09:33 -0600, John Verhaeg wrote:
> On Jan 28, 2011, at 8:07 AM, John Doyle wrote:
>
> > I vote for 1 also, but I think that 3 is not a good option. Just
> > like the timer we're making a decision for the user that they may
> > not like. Sure, the user can clean them up individually if they
> > like, but that's onerous and someone will immediately complain.
>
>
> Correct me if I'm wrong, Barry, but I think what he's referring to
> involves not just removing cleanup, rather the whole idea of ever
> cleaning anything up unless a model is deleted (or by an admin action
> via the JON/RHQ).
>
>
> This was our initial approach when designing all of this. Given where
> you're at now, of course, that whole plan would be something you'd
> have to do in 7.4 or later. But the idea behind this approach does
> not involve the user individually cleaning up anything. It would
> require the ability to compare a timestamp or something similar
> between the local PVDB and the one deployed on the server (which Teiid
> doesn't provide currently), and would mean lots of PVDBs would remain
> on the server, therefore calling for some way to automatically filter
> their presence from JON/RHQ/Designer when viewing deployed VDBs
> (unless a non-persisted flag is turned on). This also is something we
> discussed in the past.
>
>
> The advantages behind this approach are 1) we no longer need to worry
> about multiple timeframes in our tooling where we need to do cleanup
> (i.e., startup or shutdown), which is fairly time consuming, involves
> non-trivial code, and leaves the user/Designer in an awkward situation
> if the server isn't available at those times, and 2) Designer would
> re-use PVDBs from previous sessions, again saving lots of time and
> allowing the user to choose another server if the current one is down
> without having to regenerate all of the local PVDBs.
>
> > I would combine #2 with a workspace preference. Prompt with #2
> > on shutdown, with the option to "remember my choice and do this
> > every time'. The preference could be flipped manually if they
> > changed their mind.
> >
> > ~jd
> >
> >
> > ____________________________________________________________________
> > So we really have a couple of options for this release that
> > would involve minimal coding.
> >
> > 1) remove the timer. User can cancel if they wish
> >
> > 2) Add a Yes/No "You have deployed Preview Artifacts on
> > "xxxxx server". Do you wish to clean up 'Designer Preview
> > Artifacts'?" dialog during shut-down to give the user a
> > choice.
> >
> > 3) remove the clean-up at shut-down all together
> >
> > 4) do nothing
> >
> > We had talked about 3) awhile back and at length. Leaving
> > deployed Preview artifacts laying around may or may not be a
> > bad thing. We chose to prevent that with the knowledge that
> > keeping them "clean" would have it's drawbacks too.
> >
> > I vote for 1) at this time and with a 5.2 planned for a few
> > months out, keep the dialog going and gather feedback. If
> > folks get used to and understand Preview artifacts, then
> > maybe we can do 3)
> >
> > Barry
> >
> >
> > ____________________________________________________________
> > From: "John Doyle" <jdoyle at redhat.com>
> > To: rareddy at redhat.com
> > Cc: "Steven Hawkins" <shawkins at redhat.com>, "Barry Lafond"
> > <blafond at redhat.com>, "Johnny Verhaeg"
> > <jverhaeg at redhat.com>, "Daniel Florian"
> > <dflorian at redhat.com>
> > Sent: Friday, January 28, 2011 7:26:48 AM
> > Subject: Re: Preview VDB Cleanup
> >
> > I also agree that we should eliminate the timer. We're
> > making an assumptions about the user's preference there.
> >
> > Ramesh, would be possible to implement the delete such that
> > it just flags the VDB and DS for delete and returns, then
> > the delete is actually performed on another thread? I can't
> > imagine there's much corrective action someone is going to
> > take through the admin API in the event that Delete fails.
> >
> > ~jd
> >
> > ----- Original Message -----
> > > Dan,
> > >
> > > Yes, I would get rid of the timer but keep the cancel
> > button just in
> > > case user want to shutdown fast. There is noway to delete
> > all the
> > > previews at a time, as currently Teiid does not
> > distinguish between
> > > regular and preview data sources. It can not delete by its
> > own because
> > > it does not know Designer is disconnected.
> > >
> > > Yes, we need to clean up each time startup/shutdown and
> > switch of the
> > > server connection.
> > >
> > > It is quite possible that every time server is restarted
> > it can
> > > auto-clean all the preview stuff automatically, however
> > this may be
> > > too
> > > late for this iteration. If we can agree on this we can do
> > it in 7.4
> > >
> > > Ramesh..
> > >
> > >
> > > On Thu, 2011-01-27 at 15:26 -0500, Daniel Florian wrote:
> > > > Hi Guys,
> > > >
> > > > I'm working a couple issues (JBDS-1514, TEIIDDES-714)
> > that deal with
> > > > cleanup of preview artifacts from the Teiid server.
> > After letting
> > > > you guys know what we currently do, I was hoping you
> > might have
> > > > ideas of ways to improve this. Here is the way things
> > work now:
> > > >
> > > > When shutdown of JBDS/Designer occurs, an Eclipse job,
> > for each
> > > > PVDB, is created. Each job executes
> > Admin.deleteVDB(String, int) and
> > > > then Admin.deleteDataSource(String). When the second of
> > those Admin
> > > > API methods return the job finishes. During shutdown,
> > the user is
> > > > presented a dialog that displays a count of how many
> > cleanup jobs
> > > > are scheduled/running. The count of remaining jobs is
> > updated in the
> > > > dialog as the jobs finish. The user is free to cancel
> > the dialog,
> > > > which cancels any scheduled/running jobs, which allows
> > shutdown to
> > > > continue. In addition to all of that, there is a timer
> > that expires
> > > > after (10 seconds + 1/4 second per job) that
> > automatically cancels
> > > > any scheduled/running jobs. It is quite common for the
> > timer to
> > > > cancel the jobs before they are all finished. We are
> > thinking of
> > > > getting rid of this timer so that the jobs will always
> > finish unless
> > > > the dialog is canceled by the user. Whenever there are
> > cleanup jobs
> > > > that don't finish there are artifacts that don't get
> > cleaned up.
> > > >
> > > > If there was only a way to tell Teiid to delete the
> > PVDB(s) and
> > > > preview data source(s) and not have to wait for a
> > response. Is there
> > > > a way to do that using Admin API or maybe using Java
> > threading in
> > > > some way.
> > > >
> > > > We do cleanup in other scenarios other than shutdown
> > (switching
> > > > servers is one example) but the cleanup jobs are always
> > run and the
> > > > user cannot cancel them (unless they know how to kill
> > jobs within
> > > > Eclipse that is).
> > > >
> > > > One thing we are planning to do is cleanup the artifacts
> > each time a
> > > > connection is made to Teiid. This would cleanup
> > artifacts left over
> > > > from the last shutdown or connection failure. The goal
> > is to not
> > > > have to manually cleanup any of these preview artifacts.
> > Not sure if
> > > > that goal can be completely realized though.
> > > >
> > > > An email reply or a comment to either of the JIRAs is
> > much
> > > > appreciated.
> > > >
> > > > Thanks,
> > > >
> > > > Dan
> > > >
> > > >
> >
> >
> >
> >
>
> JPAV
>
>
>
>
>
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
More information about the teiid-designer-dev
mailing list