[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] bug or not

I'd agree if you are using a service constantly, it doesn't makes sense to release it after each use. It is less clear when it is not a constant need.

Of course, HttpService perhaps causes acute pain since it is from a time before the whiteboard pattern...

-> richard

On Apr 28, 2014 9:54 PM, "Thomas Watson" <tjwatson@xxxxxxxxxx> wrote:

I meant for any service that maintains state for the duration of usage for each using bundle.  Luckily that is not common for the services that the OSGi specification defines.  HttpService is probably the most commonly used one that has to maintain state for using bundles.  Regardless of that, using a pattern that will constantly get/unget the same service over and over cannot perform as well as using some higher level API like SerivceTracker or declarative models like DS, or if you must use raw BundleContext APIs then caching it yourself.  If it is a rarely used service and you don't need it that often then I guess using the get/unget each time is not that costly, but it still does not seem like something we would want to recommend for services that are often used.  Regardless of how cheap it is to construct there is still more code you have to run to construct and get it each time.

Tom



Inactive hide details for Richard Hall ---04/28/2014 08:08:47 PM---If you only meant for registering resources with the HttpSerRichard Hall ---04/28/2014 08:08:47 PM---If you only meant for registering resources with the HttpService, then i can agree with that. :-)

From: Richard Hall <heavy@xxxxxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 04/28/2014 08:08 PM
Subject: Re: [equinox-dev] bug or not
Sent by: equinox-dev-bounces@xxxxxxxxxxx





If you only meant for registering resources with the HttpService, then i can agree with that. :-)

-> richard

On Apr 28, 2014 8:59 PM, "Thomas Watson" <tjwatson@xxxxxxxxxx> wrote:

    But for the HttpService I consider this an anti-pattern.  When a bundle's usecount reaches zero the HttpService implementation must unregister all resources registered by that bundle.  If that is really what the webconsole bundle wants then that is fine and I agree with you.  But if the webconsole has resources (servlets) it does not want unregisered then it better keep its usecount of the service (it is still using to serve resources) greater than zero.

    Tom



    Inactive hide details for "Richard S. Hall" ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: >"Richard S. Hall" ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: >

    From:
    "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
    To:
    Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
    Date:
    04/28/2014 05:34 PM
    Subject:
    Re: [equinox-dev] bug or not
    Sent by:
    equinox-dev-bounces@xxxxxxxxxxx




    On 4/28/14, 17:37 , Thomas Watson wrote:

      Is your ServiceFactory.ungetService getting called each time?  If so then it is likely the felix webconsole is using an anti pattern like this:

      HttpService service = bc.getService(httpServiceRef);
      /// do some work with http service
      bc.ungetService(httpServiceRef);


    Is this really an anti-pattern? It doesn't seem so to me. If so, why don't we just deprecate ungetService() and tell all bundle implementers to not worry about ungetting, since they framework will do it for you when the bundle stops?

    The fact that ungetting and recreating may be costly is an issue for the service implementer, it would seem, not the service consumer. If it costs a lot to create instances, the service factory could consider doing caching of instances and reusing them on subsequent requests.

    Having client bundles call ungetService when they are done with a service that they may not use again for a while seems reasonable to me.

    -> richard


      If they are getting/ungetting the service each time they are interacting with the service then the usecount for the service goes to zero for each usage which then causes the framework to free the service instance object.  The should be using something like a ServiceTracker to avoid this kind of anti-pattern.

      Tom




      Inactive hide details for Raymond Auge ---04/28/2014
          04:26:50 PM---I agree that I should NOT have to implement this
          code. HowevRaymond Auge ---04/28/2014 04:26:50 PM---I agree that I should NOT have to implement this code. However, I'm having to do so in order to work

      From:
      Raymond Auge <raymond.auge@xxxxxxxxxxx>
      To:
      Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
      Date:
      04/28/2014 04:26 PM
      Subject:
      Re: [equinox-dev] bug or not
      Sent by:
      equinox-dev-bounces@xxxxxxxxxxx 





      I agree that I should NOT have to implement this code. However, I'm having to do so in order to work around this apparent issue.

      - Ray


      On Mon, Apr 28, 2014 at 5:23 PM, Raymond Auge <
      raymond.auge@xxxxxxxxxxx> wrote:



        On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson <
        tjwatson@xxxxxxxxxx> wrote:
          You seem to be implementing the work that the framework already does for ServiceFactory registrations.  The framework will only call your factory once as long as the use count of the service is greater than zero for a particular bundle.  The framework will then cache that service instance and keep returning it directly to the bundle without calling the ServiceFactory again.

          Am I understanding your observation correctly?  You are stating that your factory is not called multiple times for the same consuming bundle?
           



        I'm stating that when a single bundle is deployed which requests the same service multiple times the factory method is called multiple times and the bundle gets a different instance of the service each time.

        I'm not sure if there is some sort of race condition but the client bundle (in this case the felix webconsole) is requesting the HttpService mutliple times (in the same thread) and each time the equinox framework is invoking the HttpServiceFactory method returning different HttpServiceImpl instance.

        - Ray
         


          Tom




          Inactive hide details for Raymond Auge ---04/28/2014
            03:24:26 PM---Hey all, I have to write code as follows in a
            ServiceFactoryRaymond Auge ---04/28/2014 03:24:26 PM---Hey all, I have to write code as follows in a ServiceFactory impl in order for my 



          From:
          Raymond Auge <raymond.auge@xxxxxxxxxxx>
          To:
          Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
          Date:
          04/28/2014 03:24 PM

          Subject:
          [equinox-dev] bug or not
          Sent by:
          equinox-dev-bounces@xxxxxxxxxxx 





          Hey all,

          I have to write code as follows in a ServiceFactory impl in order for my factory to always return the same instance per bundle running on equinox 3.8.0.v20120529-1548

          ===============================================
          public HttpService getService(
          Bundle bundle, ServiceRegistration<HttpService> registration) {

          HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);

          if (httpServiceImpl != null) {
          return httpServiceImpl;
          }

          httpServiceImpl = new HttpServiceImpl(
          bundle, contextController, legacyServiceIdGenerator);

          serviceMap.putIfAbsent(bundle, httpServiceImpl);

          return httpServiceImpl;
          }
          ===============================================

          This seems clearly wrong as per the spec.

          It's certainly calling the getService method of the ServiceFactory which I'm guessing means it's not incorrectly registered.

          What could I be doing wrong? Was this ever a bug in equinox that was later resolved?

          --

          Raymond Augé (@rotty3000)
          Senior Software Architect

          Liferay, Inc. (@Liferay)
          _______________________________________________
          equinox-dev mailing list

          equinox-dev@xxxxxxxxxxx
          https://dev.eclipse.org/mailman/listinfo/equinox-dev


          _______________________________________________
          equinox-dev mailing list

          equinox-dev@xxxxxxxxxxx
          https://dev.eclipse.org/mailman/listinfo/equinox-dev





        --

        Raymond Augé (@rotty3000)
        Senior Software Architect

        Liferay, Inc. (@Liferay)




      --

      Raymond Augé (@rotty3000)
      Senior Software Architect

      Liferay, Inc. (@Liferay)
      _______________________________________________
      equinox-dev mailing list

      equinox-dev@xxxxxxxxxxx
      https://dev.eclipse.org/mailman/listinfo/equinox-dev



      _______________________________________________
      equinox-dev mailing list

      equinox-dev@xxxxxxxxxxx
      https://dev.eclipse.org/mailman/listinfo/equinox-dev


    _______________________________________________
    equinox-dev mailing list

    equinox-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/equinox-dev


    _______________________________________________
    equinox-dev mailing list

    equinox-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/equinox-dev
    _______________________________________________
    equinox-dev mailing list
    equinox-dev@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

GIF image