BTW, a very nice way of handling this queuing (i.e. async) might be OSGi promises!
- Ray On Tue, Jan 24, 2017 at 3:39 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > > 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) > -- *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
