Grouper Users - Open Discussion List

[Jim Fox <>]

> Have you analyzed your tables and rebuilt your indexes?  Do you do this 
> automatically periodically?  I think its not the cache that is taking a
> long time, its the query to the group subject source

I don't think so.  Database is analyzed regularly.

This is the sequence that seems to cause the trouble:

1) saveGroup

2) set some atttributes on the group

3) SourceFinder.findByIdentifier(some_id)  [ in this case it is a dns name 
(gws.cac.washington.edu)

   Log for that shows: ( ... = SourcesXmlResolver$LogLabelCallable.call(174) )

   2018-08-27 13:30:56,662: ... findByIdentifier on source: uwwi, 
'gws.cac.washington.edu', time in millis: 1
   2018-08-27 13:30:56,662: ... findByIdentifier on source: g:isa, 
'gws.cac.washington.edu', time in millis: 0
   2018-08-27 13:30:56,673: ... findByIdentifier on source: g:gsa, 
'gws.cac.washington.edu', time in millis: 10
   2018-08-27 13:30:56,674: ... findByIdentifier on source: uwpds, 
'gws.cac.washington.edu', time in millis: 1
   2018-08-27 13:31:16,612: ... findByIdentifier on source: grouperEntities, 
'gws.cac.washington.edu', time in millis: 19937
   2018-08-27 13:31:16,613: ... findByIdentifier on source: eppn, 
'gws.cac.washington.edu', time in millis: 1
   2018-08-27 13:31:16,616: ... findByIdentifier on source: grouperExternal, 
'gws.cac.washington.edu', time in millis: 2
   2018-08-27 13:31:16,618: ... findByIdentifier on source: dns, 
'gws.cac.washington.edu', time in millis: 1
   2018-08-27 13:31:16,618: ... SourcesXmlResolver: Using threads: false, 
time in millis: 19956

The delay is always at the grouperEntities source.  And it seems to happen 
only after a saveGroup. And only on the first findByIdentifier after the 
saveGroup.  After that it works fine.

I can avoid the delay by doing findByIdentifierAndSource, specifying sources 
where I expect to find something.  Especially avoiding grouperEntities.

Jim