[cle-release-team] SAK-22978

[Jean-Francois Leveque]

AZ gets a +1 on this. If all is fine, why keep a property for switching 
it off?

J-F

On 23/01/2013 16:58, Neal Caidin wrote:
> Thanks for cc'ing in the CLE release team.
>
> For those who need a short summary, the debate is whether now that this
> has been completed:
>
> https://jira.sakaiproject.org/browse/SAK-22978 - Performance issue with
> group member items in gradebook
>
>
> do we still need a property to turn off the group membership lookup in
> the gradebook? :
>
> https://jira.sakaiproject.org/browse/SAK-23004
>
>
> Details in thread below.
>
> Cheers,
> Neal
>
>
>
> On Jan 23, 2013, at 8:25 AM, Aaron Zeckoski <azeckoski at unicon.net
> <mailto:azeckoski at unicon.net>> wrote:
>
>> I don't think we should have random properties to turn off things that
>> might be an issue but are currently not. Considering the other areas
>> of Sakai which are much worse performance issues than this it seems
>> like we are stuck on this topic. I suggest that unless there are
>> current performance problems with this specific feature that we drop
>> this and move on to other more pressing issues for this release.
>>
>> -AZ
>>
>>
>> On Wed, Jan 23, 2013 at 8:07 AM, Noah Botimer <nbotimer at unicon.net
>> <mailto:nbotimer at unicon.net>> wrote:
>>> I agree, but I think we already have a way to manage badly behaved tools.
>>>
>>> My feeling is that we should be most concerned with the core release
>>> here.
>>> I'd hesitate to put in a global kill switch to protect specific core
>>> functionality from a theoretical, defective add-on. I'm quite sure
>>> that no
>>> one has implemented a contrib provider yet.
>>>
>>> There is already an amount of effort and familiarity required to run any
>>> given contrib tool, so it doesn't particularly bother me to use the
>>> mechanism in place: just don't register the troublesome provider. I think
>>> that keeps the focus, responsibility, and fix closest to the potential
>>> issue. Now that we're pretty confident in the general, core
>>> performance, I
>>> think this is the way to go.
>>>
>>> I think this, along with many other things, is up for consideration if we
>>> get to the point where we have cluster-wide, runtime configuration.
>>>
>>> For the hacky amongst you, it's possible to manage an emergency at
>>> runtime
>>> to avoid a restart. Drop a JSP somewhere, get the
>>> GradebookExternalAssessmentService bean, and unregister the flaky
>>> provider.
>>> Then you could prepare for a scheduled restart in relative calm.
>>>
>>> Thanks,
>>> -Noah
>>>
>>>
>>> On 01/22/2013 08:12 PM, Matthew Jones wrote:
>>>
>>> I think the only thing that concerned me about *removing* the property
>>> rather than switching the default, is that if some other tool went and
>>> implemented the isAssignmentGrouped in their provider that we didn't know
>>> about yet, and had bad performance (say a contrib tool or something)
>>> there
>>> would be no way to turn off this feature. Say if mneme or something
>>> did it,
>>> just as an example.
>>>
>>> I want to have seen the end of this, but it just feels like we might not
>>> have seen the end . . . ;(
>>>
>>>
>>> On Sun, Jan 20, 2013 at 2:27 PM, Neal Caidin
>>> <nealcaidin at sakaifoundation.org
>>> <mailto:nealcaidin at sakaifoundation.org>> wrote:
>>>>
>>>> Hi Noah,
>>>>
>>>> Yes, those properties are indeed a mixed blessing. I guess if nobody has
>>>> any objections then we should simply inform the CLE release team?
>>>>
>>>> Neal
>>>>
>>>
>>
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile