[sakai-core-team] Strange behaviour in master

Tue Mar 31 07:24:54 PDT 2015

Do we have a Jira yet for this issue?

Seems like we need one!

Thanks,
Neal

On Tue, Mar 31, 2015 at 10:19 AM, Earle Nietzel <enietzel at anisakai.com>
wrote:

> I should also add that I even removed the patch in KNL-1325 and still
> saw the same issues that Steve reported.
>
> On Tue, Mar 31, 2015 at 10:14 AM, Earle Nietzel <enietzel at anisakai.com>
> wrote:
> > Here was my email from previously looking a this issue,
> >
> > So I double checked the changes in KNL-1325 and it does not affect
> this...
> >
> > What I found was that this cache
> > org.sakaiproject.authz.api.SecurityService.cache
> > is causing the issue your seeing.
> >
> > This is the method that is being checked in SiteAction
> > boolean allowUpdateSite = SiteService.allowUpdateSite(siteId);
> >
> > which corresponds to this service method:
> > org.sakaiproject.authz.impl.SakaiSecurity.checkAuthzGroups(String,
> > String, String, Collection<String>)
> >
> > Next would need to look at invalidation around this cache, but thats
> > all I have for today!
> >
> > On Tue, Mar 31, 2015 at 9:11 AM, JOSE MARIANO LUJáN GONZáLEZ
> > <jmariano at um.es> wrote:
> >> Hi all,
> >>
> >> The use-case I described (useful when testing) is still happening in
> Nightly
> >> servers. I don't remember any action since the last email.
> >>
> >> Thanks,
> >> Mariano
> >>
> >>
> >> El 31/03/2015 14:33, Neal Caidin escribió:
> >>
> >> Did this ever get resolved fully?
> >>
> >> I'm hoping to get some QA testing during April.
> >>
> >> Thanks,
> >> Neal
> >>
> >>
> >> On Thu, Mar 12, 2015 at 9:23 PM, Sam Ottenhoff <ottenhoff at longsight.com
> >
> >> wrote:
> >>>
> >>> So does reverting KNL-1325 fix all issues reported in this thread?
> >>>
> >>> Earle, any thoughts here?
> >>>
> >>> On Thu, Mar 12, 2015 at 7:41 PM, José Mariano Luján <jmariano at um.es>
> >>> wrote:
> >>>>
> >>>> Hi everyone!
> >>>>
> >>>> Agree with that Steve, the problem reported by Juanjo is really
> important
> >>>> for QA purposes because I believe that when testing, most people do
> the
> >>>> following:
> >>>>
> >>>> 1- login to a nightly server using demo accounts (instructor, ta,
> >>>> student…)
> >>>> 2- create a site (maybe using demo rosters)
> >>>> 3- log in with different users to reproduce the jira you are testing
> >>>> 4- Right now, at this point, only the site creator will be enrolled in
> >>>> the site.
> >>>>
> >>>> So, lets say you are testing a Samigo ticket: instructor creates the
> >>>> site, then creates an exam, then you try to log in with one student
> but it
> >>>> is not in the site yet. Same happens with assignments. Also, if you
> are
> >>>> testing something with roster or site info, no one is in the site
> until some
> >>>> time has passed…
> >>>>
> >>>> Hope that helps to understand the problem,
> >>>> Thanks!
> >>>> Mariano
> >>>>
> >>>> El 12/3/2015, a las 23:50, Steve Swinsburg <steve.swinsburg at gmail.com
> >
> >>>> escribió:
> >>>>
> >>>> Further, I think any update should occur immediately, so updating
> perms
> >>>> or roles should call the refresh.
> >>>>
> >>>> On 13 Mar 2015 09:49, "Steve Swinsburg" <steve.swinsburg at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> This actually sounds pretty similar to an issue I noticed this
> morning
> >>>>> where a user was promoted to maintainer but didnt get the proper set
> of
> >>>>> permissions until after a cache flush.
> >>>>>
> >>>>> Of interest is that they got some maintain permissions immediately,
> ie
> >>>>> could add participants, but not see grades etc so this might show an
> >>>>> inconsistency in how tools check perms.
> >>>>>
> >>>>> https://jira.sakaiproject.org/browse/SAK-29153
> >>>>>
> >>>>> On 12 Mar 2015 22:38, "JUAN JOSé MEROñO SáNCHEZ" <jjmerono at um.es>
> wrote:
> >>>>>>
> >>>>>> There is a background process that runs every minute by default to
> >>>>>> check a queue of realms and perform refreshAuthzGroup's call on
> them,
> >>>>>> but before that there is a chache here:
> >>>>>>
> >>>>>>
> >>>>>>
> https://github.com/sakaiproject/sakai/blob/master/kernel/kernel-impl/src/main/java/org/sakaiproject/authz/impl/DbAuthzGroupService.java#L815
> >>>>>>
> >>>>>> Maybe I'm wrong but I think is related with this cache, Earl could
> you
> >>>>>> confirm if I'm wrong?
> >>>>>>
> >>>>>> El 11/03/2015 16:04, Matthew Jones escribió:
> >>>>>>
> >>>>>> It looks like this isn't a cache, and it is schedule by default to
> run
> >>>>>> the refresh every minute. If it's taking 20 minutes that seems like
> >>>>>> something is wrong? I think it could be *nice* if there was a way
> to force
> >>>>>> this to run (like a button on the Memory page or somewhere), but
> not sure
> >>>>>> why it would be taking so long or what to set in a test enviornment
> to
> >>>>>> change that.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Mar 11, 2015 at 9:22 AM, JUAN JOSé MEROñO SáNCHEZ
> >>>>>> <jjmerono at um.es> wrote:
> >>>>>>>
> >>>>>>> Hi Core Team,
> >>>>>>>
> >>>>>>>      I've notice a strange behaviour in master and I think is due
> to
> >>>>>>> "https://jira.sakaiproject.org/browse/KNL-1325".
> >>>>>>>      Now you're not able to see participants immediatly after
> creating
> >>>>>>> a
> >>>>>>> course site.
> >>>>>>>      I think refreshAuthGroup is cached with no one else but the
> >>>>>>> site's
> >>>>>>> creator, and participants appear only when cache expires (default
> >>>>>>> 20m?).
> >>>>>>> The "clear caches" button in administration workspace doesn't help.
> >>>>>>>      I think this is not the desire behaviour specially when you
> are
> >>>>>>> testing and you need to create course sites and use those members
> in
> >>>>>>> the
> >>>>>>> site immediatly :(
> >>>>>>>
> >>>>>>> Thanks !!
> >>>>>>> _______________________________________________
> >>>>>>> sakai-core-team mailing list
> >>>>>>> sakai-core-team at collab.sakaiproject.org
> >>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> sakai-core-team mailing list
> >>>>>> sakai-core-team at collab.sakaiproject.org
> >>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> sakai-core-team mailing list
> >>>>>> sakai-core-team at collab.sakaiproject.org
> >>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>>>>>
> >>>> _______________________________________________
> >>>> sakai-core-team mailing list
> >>>> sakai-core-team at collab.sakaiproject.org
> >>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> sakai-core-team mailing list
> >>>> sakai-core-team at collab.sakaiproject.org
> >>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> sakai-core-team mailing list
> >>> sakai-core-team at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>>
> >>
> >>
> >> --
> >> ******************************************
> >> José Mariano Luján González - Aula Virtual
> >> Area de Tecnologías de la Información
> >> y las Comunicaciones Aplicadas (ATICA)
> >> UNIVERSIDAD DE MURCIA - http://www.um.es
> >>
> >>
> >> _______________________________________________
> >> sakai-core-team mailing list
> >> sakai-core-team at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >>
> >
> >
> >
> > --
> > earle,
> > asahi net int.
>
>
>
> --
> earle,
> asahi net int.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150331/560b7785/attachment-0001.html 