9:33 a.m.
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(a)redhat.com>
To: rareddy(a)redhat.com
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "Barry Lafond"
<blafond(a)redhat.com>, "Johnny Verhaeg" <jverhaeg(a)redhat.com>,
"Daniel Florian" <dflorian(a)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
8:40 a.m.
New subject: Preview VDB Cleanup
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(a)redhat.com>
> To: rareddy(a)redhat.com
> Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "Barry
Lafond"
> <blafond(a)redhat.com>, "Johnny Verhaeg"
> <jverhaeg(a)redhat.com>, "Daniel Florian"
> <dflorian(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
9:44 a.m.
New subject: Preview VDB Cleanup
If I understand correctly, the whole reason we deviated from this initial design was due
to a JIRA logged by Ramesh predicated on the idea that there'd be some way for the
local PVDBs to get out-of-sync with the server outside of the Designer. I'd like to
hear from Ramesh why he thought this was possible, because I can't figure out how that
would happen in any reasonable manner, other than in some very rare edge-case.
On Jan 28, 2011, at 9:33 AM, 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.
JPAV
5094
days inactive
5094
days old
teiid-designer-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
John Verhaeg -
Ramesh Reddy