Smalltalk › Gemtalk › GLASS

WAGemStoneMaintenanceTask

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

NorbertHartl

WAGemStoneMaintenanceTask

While working on my maintenance scripts I discovered WAGemStoneMaintenanceTask. I love the idea to have the tasks in the image and trigger it from the outside. For my multi user setup I just did

"copy startMaintenance30 start-maintenance-username" and changed the line

WAGemStoneMaintenanceTask performTasks: count.

to

(WAGemStoneMaintenanceTask taskNamed: 'Seaside Session Expiration' ) performTask: count.

Btw. WAGemStoneMaintenanceTask class>>taskNamed: is lacking the return ^. I've uploaded a version that fixes it.
I think the taskNamed: approach can be useful for the commandline scripts. This way you could even specify the task as a commandline parameter.

However I do not understand the rationale why it is WA... maintenance task. In my case it does not work. The maintenance task contains two tasks, the "seaside session expiry" which works and "mark for collect" which doesn't. Only DataCurator is allowed to do a "mark for collect" but it is the only user in my system that doesn't have seaside installed. I think maintenance task deserves a place closer to the core :)

What do you mean?

Norbert

Dale Henrichs

Re: WAGemStoneMaintenanceTask

On 10/07/2010 09:52 AM, Norbert Hartl wrote:

> While working on my maintenance scripts I discovered WAGemStoneMaintenanceTask. I love the idea to have the tasks in the image and trigger it from the outside. For my multi user setup I just did
>
> "copy startMaintenance30 start-maintenance-username" and changed the line
>
> WAGemStoneMaintenanceTask performTasks: count.
>
> to
>
> (WAGemStoneMaintenanceTask taskNamed: 'Seaside Session Expiration' ) performTask: count.
>
> Btw. WAGemStoneMaintenanceTask class>>taskNamed: is lacking the return ^. I've uploaded a version that fixes it.
> I think the taskNamed: approach can be useful for the commandline scripts. This way you could even specify the task as a commandline parameter.
>
> However I do not understand the rationale why it is WA... maintenance task. In my case it does not work. The maintenance task contains two tasks, the "seaside session expiry" which works and "mark for collect" which doesn't. Only DataCurator is allowed to do a "mark for collect" but it is the only user in my system that doesn't have seaside installed. I think maintenance task deserves a place closer to the core :)
>
> What do you mean?
>
> Norbert
>
>
>

Norbert,

MaintenanceTask and SeviceTask (see Seaside-GemStone-ServiceTask package
in http://seaside.gemstone.com/ss/Seaside30) are works in progress so I
am interested in evolving them in a more useful direction ...

At the time that I created WAGemStoneMaintenanceTask I wanted to allow
users/projects to programatically add additional tasks to the
maintenance vm ....

When I started the service task example it was obvious that
WAGemStoneMaintenanceTask could be extended ...

Not long after Nick started work on the ServiceTask in earnest it became
obvious that things should/could be structured differently.

I'm inclined to leave WAGemStoneMaintenanceTask as it is and start work
on a separate framework that takes WAGemStoneMaintenanceTask as a
starting point and adds in what you are doing and what was done for the
serviceTask to create a new and better (and incompatible) framework for
managing "task vms"...

Dale

Nick

Re: WAGemStoneMaintenanceTask

Hi Dale,

Not long after Nick started work on the ServiceTask in earnest it became obvious that things should/could be structured differently.

I'm inclined to leave WAGemStoneMaintenanceTask as it is and start work on a separate framework that takes WAGemStoneMaintenanceTask as a starting point and adds in what you are doing and what was done for the serviceTask to create a new and better (and incompatible) framework for managing "task vms"...

I've been meaning to follow up our ESUG discussions about the ServiceTask vs future interface. On reflection I agree that using "future" is potentially confusing as the current semantics are somewhat different. I do like extending BlockContext so that an arbitrary block can be wrapped as a background task though. Perhaps I could replace "future" with "serverBackgroundTask" and a matching implementation in the MockGemstone repository.

That said the current code is working well for me..,

Nick

Dale Henrichs

Re: WAGemStoneMaintenanceTask

On 10/07/2010 11:05 AM, Nick Ager wrote:

> Hi Dale,
>
>
> Not long after Nick started work on the ServiceTask in earnest it
> became obvious that things should/could be structured differently.
>
> I'm inclined to leave WAGemStoneMaintenanceTask as it is and start
> work on a separate framework that takes WAGemStoneMaintenanceTask as
> a starting point and adds in what you are doing and what was done
> for the serviceTask to create a new and better (and incompatible)
> framework for managing "task vms"...
>
>
> I've been meaning to follow up our ESUG discussions about the
> ServiceTask vs future interface. On reflection I agree that using
> "future" is potentially confusing as the current semantics are somewhat
> different. I do like extending BlockContext so that an arbitrary block
> can be wrapped as a background task though. Perhaps I could replace
> "future" with "serverBackgroundTask" and a matching implementation in
> the MockGemstone repository.
>
> That said the current code is working well for me..,
>
> Nick

Nick,

I agree, the only issue I had was that the #future name should be
reserved for the "standard" future implementation, #serverBackgroundTask
sounds good.

Dale