Alexander,

Sorry for the delay in getting back to you. I’ve been trying to do some testing 
on my end with this. So I have built a service factory with both calls 
(celix_bundelcontext_registerServiceFactory & 
bundelcontext_registerServiceFactory) and they both give the same result in 
that they won’t spin up more than 1 service. I am currently using the Remote 
Service Admin functionality and launching my Java application twice inside of 
Eclipse (with different ports assigned and 2 different Eclipse instances) and 
making 2 separate calls over to my C application. 

I may not be doing your #2 below with the service tracking though. Is this 
needed with RSA or is something happening in the background to take care of 
this through your discovery/topology manager?

Interceptors have proven to me that the call is coming through it’s just not 
spinning up a new service. 

I’ll look into service tracking today. Please respond and let me know if you 
think this is what could be wrong. 

Thanks,
Brian

Sent from my iPhone

> On Aug 4, 2020, at 4:01 AM, Alexander Broekhuis <a.broekh...@gmail.com> wrote:
> 
> Hi Brian,
> 
> Before answering your questions, I think it is important to realize that
> most of the framework logic is handled on 1 thread. So in your example,
> using a factory (multiple services) is not enough. You would still need to
> spin up a thread in the service yourself.
> 
> Functionally there should be no difference between the 2. The celix_
> prefixed functions are newer, with the added namespace, but also with an
> easier api to register services. So those are better to use. Do you
> experience any issues/differences with either call?
> 
> In short, it should work like this:
> 
> 1) create a new service factory and register, see eg for an old api example:
> bundles/logging/log_service_v2/src/log_service_activator.c:115
> bundles/logging/log_service_v2/src/log_factory.c
> 
> 2) user registered service using a service tracker or dependency manager
> 
> For each new bundle using the service, a new instance is made. Perhaps this
> is where the problem is, the new service is created per using bundle. My
> previous reply didn't mention that.
> So if the consumers are from the same bundle, they will all get the same
> service (and not a new instance). See the javadoc for the factory at [1].
> 
> [1]:
> https://docs.osgi.org/javadoc/r4v42/org/osgi/framework/ServiceFactory.html
> 
> Op ma 3 aug. 2020 om 21:55 schreef Brian Michael <brian.m7...@gmail.com>:
> 
>> Alexander,
>> 
>> What is the functionality difference between:
>> celix_bundelcontext_registerServiceFactory
>> bundelcontext_registerServiceFactory
>> 
>> Also. I’m wanting the new service spin up per other bundle calling this
>> service. So I have org.Algo1 that wants this C service and I have org.Algo2
>> that also wants this C service. From reading up it appears that the service
>> factory is what I want I think but I built one inside of Celix and it
>> doesn’t appear to be making a new service when I perform the multiple
>> calls.
>> 
>> Thanks,
>> Brian
>> 
>> Sent from my iPhone
>> 
>>> On Aug 3, 2020, at 10:37 AM, Alexander Broekhuis <a.broekh...@gmail.com>
>> wrote:
>>> 
>>> Hi Brian,
>>> 
>>> Most of the services concepts follow the OSGi Specifications [1]. A lot
>> of
>>> theory can be found there.
>>> 
>>> Regarding your question, a service factory does not provide a new service
>>> for each call, but for each service reference. So each component
>> requesting
>>> a service provided by a service factory, will get its own instance. This
>> is
>>> regardless of the usage of a service tracker or dependency manager etc.
>>> 
>>> While it is possible to get a new service for each of the calls, I wonder
>>> if that is what you want. Reading your scenario, something like a
>>> threadpool makes more sense. There are no restrictions to adding a
>>> threadpool inside a component yourself, which is then used by function
>>> handling the calls.
>>> 
>>> In utils there is a thpool implementation [2] available, which is used by
>>> some experimental code. I personally don't have any experience with it,
>> but
>>> perhaps it can help you.
>>> 
>>> [1]: https://www.osgi.org/developer/specifications/
>>> [2]: https://github.com/Pithikos/C-Thread-Pool/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Op za 1 aug. 2020 om 17:38 schreef Brian Michael <brian.m7...@gmail.com
>>> :
>>> 
>>>> Hello,
>>>> 
>>>> I have a question in regards to the service factory capabilities. I want
>>>> to have Celix churn up a new service for each call that is coming in. An
>>>> example would be say I have a function that is just stuck in a while
>> loop
>>>> for 3 minutes before it exits and it prints stuff to screen. I want to
>> be
>>>> able to have multiple calls coming in and running. Currently the
>> incoming
>>>> calls have to wait their turn in order to use the service. Does the
>> service
>>>> factory churn up a new service per call to take care of this or do I
>> need
>>>> to go another route?
>>>> 
>>>> Thanks,
>>>> Brian
>>>> 
>>>> Sent from my iPhone
>>> 
>>> 
>>> 
>>> --
>>> Met vriendelijke groet,
>>> 
>>> Alexander Broekhuis
>> 
> 
> 
> -- 
> Met vriendelijke groet,
> 
> Alexander Broekhuis

Reply via email to