Is it possible to make referenced OSGi service constrained with timeout?

[Umesh Rajani]

Here, in below code snippet, DirectoryControllers wait too much for getting referenced services available, if DirectoryControllers having one or two reference then it's OK but I will have around 10 service reference in DirectoryControllers component so it is taking too much time to start invalid configured services.

For every invalid referenced service, it tries three time to get activated reference service.

@Component(immediate = true, configurationPolicy = ConfigurationPolicy.IGNORE,name="directory.comp")
    public class DirectoryControllers
    {
            @Reference(policy=ReferencePolicy.STATIC,cardinality=Refer‌​enceCardinality.OPTI‌​ONAL,policyOption=Re‌​ferencePolicyOption.‌​GREEDY)
            private volatile IZimbra zimbra;
   
            @Reference(policy=ReferencePolicy.STATIC,cardinality=Refer‌​enceCardinality.OPTI‌​ONAL,policyOption=Re‌​ferencePolicyOption.‌​GREEDY)
            private volatile IOpenDJ opendj;
   
            @Reference(policy=ReferencePolicy.STATIC,cardinality=Refer‌​enceCardinality.OPTI‌​ONAL,policyOption=Re‌​ferencePolicyOption.‌​GREEDY)
            private volatile IOpenIDM openidm;
   
            private ServletRegistration _registration;
   
            @Activate void activate(BundleContext bc) throws ServletException, NamespaceException
            {
                 AppProvisioners provisioners=new AppProvisioners(zimbra,openidm,opendj);
                _registration = ServletRegistration.register(
                    bc, _httpService, "/middleware",
                    new ProvisioningController(_db,provisioners),
                    new UserEnrollmentController(_db,provisioners)
                );
            }
    }

I'm here using declarative service, so do we have any reference property like 'timeout' exist in blueprint?

Thank you.

[Neil Bartlett]

Could you please clarify your question. In the code, all of the references are optional, therefore DS will not wait at all for the services that are not available.

Neil

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Umesh Rajani]

Ohh, Neil, it's my mistake, actually zimbra service is like this:

       @Reference(policy=ReferencePolicy.DYNAMIC)

private volatile IZimbra zimbra; 

If I provide invalid configuration for zimbra then it tries to activate zimbra component three times, so it takes too much times.

[Neil Bartlett]

On 15 Jun 2017, at 11:36, Umesh Rajani <rajan...@gmail.com> wrote:

Ohh, Neil, it's my mistake, actually zimbra service is like this:

       @Reference(policy=ReferencePolicy.DYNAMIC)

private volatile IZimbra zimbra; 

In this case the reference is mandatory but can be changed dynamically after startup. Mandatory means mandatory, there is no timeout: if an IZimbra service never appears then your component will never activate.

If I provide invalid configuration for zimbra then it tries to activate zimbra component three times, so it takes too much times.

Forgive me for stating the obvious, but how about providing valid configuration for zimbra?

[Umesh Rajani]

On Thursday, June 15, 2017 at 4:21:20 PM UTC+5:30, Neil Bartlett wrote:

On 15 Jun 2017, at 11:36, Umesh Rajani <rajan...@gmail.com> wrote:

Ohh, Neil, it's my mistake, actually zimbra service is like this:

       @Reference(policy=ReferencePolicy.DYNAMIC)

private volatile IZimbra zimbra; 

In this case the reference is mandatory but can be changed dynamically after startup. Mandatory means mandatory, there is no timeout: if an IZimbra service never appears then your component will never activate.

 

Yes, that is true. but in case of invalid configuration it tries three time then it will go ahead. 

If I provide invalid configuration for zimbra then it tries to activate zimbra component three times, so it takes too much times.

Forgive me for stating the obvious, but how about providing valid configuration for zimbra?

Actually, we are configuring IZimbra and other services very frequently and that configuration are provided by REST API, so if initial configuration is invalid then I can reconfigure it by API immediately. 

[David Jencks]

I still think you have not explained what you want to happen.  From my point of view, the component has the zimbra reference either requires it to operate properly or it doesn’t.  If it does, then the zimbra reference needs to be mandatory, and it doesn’t make sense to start it until a zimbra service is available.  If it doesn’t,  then you can make the reference optional.

I think the timeout in blueprint is there mostly because blueprint doesn’t work very well.

On Jun 15, 2017, at 4:45 AM, Umesh Rajani <rajan...@gmail.com> wrote:

On Thursday, June 15, 2017 at 4:21:20 PM UTC+5:30, Neil Bartlett wrote:

On 15 Jun 2017, at 11:36, Umesh Rajani <rajan...@gmail.com> wrote:

Ohh, Neil, it's my mistake, actually zimbra service is like this:

       @Reference(policy=ReferencePolicy.DYNAMIC)

private volatile IZimbra zimbra; 

In this case the reference is mandatory but can be changed dynamically after startup. Mandatory means mandatory, there is no timeout: if an IZimbra service never appears then your component will never activate.

 

Yes, that is true. but in case of invalid configuration it tries three time then it will go ahead. 

What??? The DS component with a mandatory reference won’t start until that reference is satisfied.  What does the “three times” refer to?

If I provide invalid configuration for zimbra then it tries to activate zimbra component three times, so it takes too much times.

Forgive me for stating the obvious, but how about providing valid configuration for zimbra?

Actually, we are configuring IZimbra and other services very frequently and that configuration are provided by REST API, so if initial configuration is invalid then I can reconfigure it by API immediately. 

Why not provide a valid configuration to start with?

You may have a real problem but I cannot figure out what it is from your explanation.

thanks

david jencks

[BJ Hargrave]

Yes. Timeout from Blueprint was an attempt to wallpaper over Blueprint's lack of support for the dynamicity of OSGi services. And that timeout is for the whole blueprint container, not just an individual referenced service.

So for DS, there is no timeout. You use a mandatory reference if your component must have the referenced service or an optional reference if your component can operate without the referenced service. For the latter case, use a dynamic, optional reference to obtain the referenced service should it later become available.

Also, if you have a REST service to alter the configuration, the REST service implementation should validate its inputs before configuring them into Configuration Admin. Then you never have an invalid configuration in Configuration Admin.

BJ

[Umesh Rajani]

Thanks Neil, BJ, djencks for your time.

Fundamentally I have used everything correct, after inputs from you experts, I thought I must be doing wrong or messed something.

Then tried with different component openidm, making it mandatory and provided configuration for openidm invalid then it spends just friction of time to give a try with invalid configuration for opeidm and so DircetoryComponent is not getting activated, but problem of time cost is observed in only case of zimbra, it tries three time if configuration is invalid. so I found out this is related to zimbra taking much time to start in case of invalid configuration.

@BJ, I use different controller and component to configure any service like opeidm, owncloud, zimbra..etc using REST. so it will activate as soon as I provide valid configuration using REST API or I can invalid any component by REST API.

Thank you all of you for your valuable time.

Umesh