[cle-release-team] SAK-22978

[Neal Caidin]

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> 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> 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> 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
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20130123/b3c6f510/attachment-0006.html