Revisit SharedInformer support and do Improvements

[yybear]

with 4.6.1

public void determineNextResync(ZonedDateTime now) { this.nextResync = now.plusSeconds(this.resyncPeriod); }

in DefaultShareIndexInformer.java

ProcessorListener<T> listener = new ProcessorListener(handler, determineResyncPeriod(resyncCheckPeriodMillis, this.resyncCheckPeriodMillis));

so using plusSeconds to get nextResync is ok?

[rohanKanojia]

@yybear : nice catch. It seems like a bug to me. Could you please create a quick PR to fix this issue?

[yybear]

@rohanKanojia : another question, in golang reflector.go
// period controls timing between one watch ending and // the beginning of the next one. period time.Duration
func NewNamedReflector(name string, lw ListerWatcher, expectedType interface{}, store Store, resyncPeriod time.Duration) *Reflector { r := &Reflector{ name: name, listerWatcher: lw, store: store, expectedType: reflect.TypeOf(expectedType), period: time.Second, resyncPeriod: resyncPeriod, clock: &clock.RealClock{}, } return r }
so in reflector.go，period is different from resyncPeriod，is just one second.
but in fabric8 if FullResyncPeriod >0 , period and resyncPeriod are all equal FullResyncPeriod.
otherwise period is set to 5 seconds by default.

this is different from reflector.go, is this ok?

[rohanKanojia]

@yybear : I'm not sure since it might be possible that client-go's codebase had undergone changes after we ported this from them. I think I have to take a look again to align informer support with latest client-go releases.

Do you mind if I pick this issue up instead? I think it might be more involved.

[yybear]

@rohanKanojia Yes, sure.