On Tue, Jan 24, 2017 at 3:23 PM, Tim Jones <tim.jo...@mccarthy.co.nz> wrote:
> Okay let's say for example that incoming data needs to stored in separate > database schemas/partitions depending upon some value within the data. We > don't know in advance what these values are so we can't pre create the > schemas/partitions before server startup, so instead when a new value > arrives we create the database schema/partition and tables, functions, > assign roles etc, then create an associated JPA persistence unit + > dependent services. > I'd be very hesitant to have all this work be the result of a single method call. Sounds scary! I'd probably do something like: - identify that a schema is needed by looking at the data - queue schema creation up in a schema queue - queue up the data in data queue - schema queue consumer does all that setup work, or if it had already been done, skip it - once ready create a data queue consumer - data queue consumer notices its data in the queue and process it Just an idea! - Ray > > Tim > > > ------------------------------ > *From: *"Raymond Auge" <raymond.a...@liferay.com> > *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> > *Sent: *Wednesday, 25 January, 2017 12:09:17 PM > > *Subject: *Re: [osgi-dev] How to determine when a new service instance > has been activated? > > > > On Tue, Jan 24, 2017 at 3:08 PM, Raymond Auge <raymond.a...@liferay.com> > wrote: > >> >> >> On Tue, Jan 24, 2017 at 3:00 PM, Tim Jones <tim.jo...@mccarthy.co.nz> >> wrote: >> >>> Ray can you please explain a little more what you mean by 'manifest the >>> schemas'? One thing I should have said is we don't know in advance of >>> server startup as to what schemas will be needed. >>> >>> BTW I have read http://www.coding-dude.com/wp/ >>> java/liferay/liferay-multi-tenancy-setup-with-shards/ >>> >> >> That article is a little dated but it's fine :) >> >> What I mean to suggest is that rather than having creation of schema be a >> side effect caused by some method call, it could probably be better >> modelled by some agent specializing in schema who once it's built a schema >> exposes it as an OSGi service. >> >> This way other components interested in schema can have real service >> dependencies on those concert services. >> > > auto-correct gaf: ...schema services... > > >> >> I hope that is a little more clear. >> >> However, I've been slightly confused by the implication of your statement: >> > we don't know in advance of server startup as to what schemas will be >> needed >> >> My question to that is; isn't that a function of somebody providing one >> or not Otherwise, I can't see how you'd magically get a schema as a result >> of a function call? To me that feels a little reverse. I think the schema >> should arrive and then others who may need it would be satisfied or not. >> >> - Ray >> >> >> >>> >>> >>> Tim >>> >>> >>> ------------------------------ >>> *From: *"Raymond Auge" <raymond.a...@liferay.com> >>> *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> >>> *Sent: *Wednesday, 25 January, 2017 11:20:37 AM >>> >>> *Subject: *Re: [osgi-dev] How to determine when a new service instance >>> has been activated? >>> >>> >>> >>> On Tue, Jan 24, 2017 at 2:17 PM, Tim Jones <tim.jo...@mccarthy.co.nz> >>> wrote: >>> >>>> Actually the remote service still calls the same 'top level' component >>>> but it is this component that will make the choice as to which set of >>>> instance of services are ultimately exercised. At the risk of going too far >>>> off topic but to illustrate the requirement, the application is a >>>> multi-tenant system that needs to be able to create and access new db >>>> schemas on the fly. I don't wont the call to create the new db schemas and >>>> the associated services to return until they have been created. >>>> >>> >>> A nice way to do this is to flip the problem on it's head and manifest >>> the schemas, once ready, as a services and have interested components >>> declare references to those services. >>> >>> - Ray >>> >>> >>> >>>> Tim >>>> >>>> >>>> >>>> ------------------------------ >>>> *From: *"Christian Schneider" <ch...@die-schneider.net> >>>> *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> >>>> *Sent: *Wednesday, 25 January, 2017 11:01:20 AM >>>> >>>> *Subject: *Re: [osgi-dev] How to determine when a new service instance >>>> has been activated? >>>> >>>> If the call is via jms then you should only start the route (and so the >>>> jms listener) once the service is injected. >>>> Christian >>>> >>>> 2017-01-24 22:45 GMT+01:00 Tim Jones <tim.jo...@mccarthy.co.nz>: >>>> >>>>> Yes the call is made by a component with the injected service and the >>>>> service reference is mandatory but the initiating call to the component is >>>>> from a remote system e.g. >>>>> >>>>> Remote system ---- (via Camel/JMS) ----> to component(s) which >>>>> reference the newly created service >>>>> >>>>> Tim >>>>> >>>>> >>>>> ------------------------------ >>>>> *From: *"Neil Bartlett" <njbartl...@gmail.com> >>>>> *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> >>>>> *Sent: *Wednesday, 25 January, 2017 9:55:34 AM >>>>> >>>>> *Subject: *Re: [osgi-dev] How to determine when a new service >>>>> instance has been activated? >>>>> >>>>> Who makes the call to the newly published service? If it is a >>>>> component with an injected service, then just make the service reference >>>>> mandatory. The component will then not be *able* to call the first service >>>>> until it is actually published. >>>>> >>>>> Most of these timing and ordering problems disappear when you break >>>>> the system down into components with injected service references. The DS >>>>> runtime takes care of the underlying complexity and gives you a simple >>>>> guarantee: for as long as your component is active, it can use its >>>>> injected >>>>> services without worrying about whether they are available yet and/or >>>>> still >>>>> available. >>>>> >>>>> Neil >>>>> >>>>> >>>>> >>>>> On 24 Jan 2017, at 20:42, Tim Jones <tim.jo...@mccarthy.co.nz> wrote: >>>>> >>>>> Thanks Neil and Christian, >>>>> >>>>> I may be going about this the wrong way but the service is ultimately >>>>> injected into other components as you have suggested Christian. But, I >>>>> don't want to return until the target service has been activated (and then >>>>> hopefully fairly quickly referenced by other services) as the programatic >>>>> call to ConfigurationAdmin.createFactoryConfiguration() is from a >>>>> remote system and the next remote call will be to the services that have >>>>> references to this newly published/activated service. If the next remote >>>>> call is too soon the call would regularly fail as the service would not >>>>> have been activated yet. While I acknowledge the next remote call can >>>>> still >>>>> fail I would rather this was the exceptional case. >>>>> >>>>> Tim >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *From: *"Neil Bartlett" <njbartl...@gmail.com> >>>>> *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> >>>>> *Sent: *Monday, 23 January, 2017 11:18:54 PM >>>>> *Subject: *Re: [osgi-dev] How to determine when a new service >>>>> instance has been activated? >>>>> >>>>> I agree with Christian but would add an exception to his rule… using >>>>> ServiceTracker.waitForService() is useful when writing unit tests. >>>>> The other options such as adding fixed-length sleeps are unreliable and >>>>> seriously damage the performance of your test runs. >>>>> >>>>> Neil >>>>> >>>>> >>>>> On 23 Jan 2017, at 06:26, Christian Schneider <ch...@die-schneider.net> >>>>> wrote: >>>>> >>>>> This exactly the expected behaviour. The @Activate method allows the >>>>> component to configure itself. The service of the component will only be >>>>> published when the @Activate method has finished. If it would be published >>>>> earlier then the service might be in an invalid state. >>>>> Btw. You should avoid using waitForService. Instead override the >>>>> addedService method of ServiceTracker and continue your initialization >>>>> only >>>>> when the service is present. Even better just inject the servcie into >>>>> another @Component. >>>>> >>>>> Christian >>>>> >>>>> 2017-01-22 21:14 GMT+01:00 Tim Jones <tim.jo...@mccarthy.co.nz>: >>>>> >>>>>> Hi, >>>>>> >>>>>> I am after some advice on the following. >>>>>> >>>>>> In general terms the problem is if a new instance of a service is >>>>>> created via a programatic call to >>>>>> ConfigurationAdmin.createFactoryConfiguration(), >>>>>> what options do I have to determine that this new service instance has >>>>>> been >>>>>> activated considering the call to .createFactoryConfiguration() returns >>>>>> immediately. >>>>>> >>>>>> I have tried setting up a service tracker with a filter for the >>>>>> specific instance of the service but I am not sure I understand the >>>>>> expected behavior of the .waitForService() method. For a small timeout >>>>>> period e.g. 1ms the call to .waitForService() returns with a null service >>>>>> as I would expect. For a longer timeout period e.g. 1000ms the call to >>>>>> .waitForService() returns with non null service and from the logs I can >>>>>> see >>>>>> that it seems to return only after the tracked service has returned from >>>>>> the @Activate method, is this the expected behavior? >>>>>> >>>>>> I also tried adding a sleep for 0.5 sec in the @Activate method of >>>>>> the tracked service and the .waitForService() still only returned after >>>>>> the >>>>>> @Activate method of that service had returned. Does the registration of a >>>>>> service have any dependency on its activation in the context of >>>>>> Declarative >>>>>> Services? Note the tracked service has @Component(immediate = true) >>>>>> >>>>>> Although the behavior is what I am after ie .waitForService() only >>>>>> seems to return after the tracked service has activated I am wondering >>>>>> if I >>>>>> am just getting lucky in this case. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Tim Jones >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OSGi Developer Mail List >>>>>> osgi-dev@mail.osgi.org >>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> >>>>> >>>>> Open Source Architect >>>>> http://www.talend.com >>>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>> (@OSGiAlliance) >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
