thanks Ray, will think it over. Tim
From: "Raymond Auge" <raymond.a...@liferay.com> To: "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> Sent: Wednesday, 25 January, 2017 12:43:33 PM Subject: Re: [osgi-dev] How to determine when a new service instance has been activated? 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 < [ mailto:raymond.a...@liferay.com | raymond.a...@liferay.com ] > wrote: On Tue, Jan 24, 2017 at 3:23 PM, Tim Jones < [ mailto:tim.jo...@mccarthy.co.nz | tim.jo...@mccarthy.co.nz ] > wrote: BQ_BEGIN 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 BQ_BEGIN Tim From: "Raymond Auge" < [ mailto:raymond.a...@liferay.com | raymond.a...@liferay.com ] > To: "OSGi Developer Mail List" < [ mailto:osgi-dev@mail.osgi.org | 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 < [ mailto:raymond.a...@liferay.com | raymond.a...@liferay.com ] > wrote: BQ_BEGIN On Tue, Jan 24, 2017 at 3:00 PM, Tim Jones < [ mailto:tim.jo...@mccarthy.co.nz | tim.jo...@mccarthy.co.nz ] > wrote: BQ_BEGIN 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/ | http://www.coding-dude.com/wp/java/liferay/liferay-multi-tenancy-setup-with-shards/ ] BQ_END 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. BQ_END auto-correct gaf: ...schema services... BQ_BEGIN 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 BQ_BEGIN Tim From: "Raymond Auge" < [ mailto:raymond.a...@liferay.com | raymond.a...@liferay.com ] > To: "OSGi Developer Mail List" < [ mailto:osgi-dev@mail.osgi.org | 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 < [ mailto:tim.jo...@mccarthy.co.nz | tim.jo...@mccarthy.co.nz ] > wrote: BQ_BEGIN 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. BQ_END 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 BQ_BEGIN Tim From: "Christian Schneider" < [ mailto:ch...@die-schneider.net | ch...@die-schneider.net ] > To: "OSGi Developer Mail List" < [ mailto:osgi-dev@mail.osgi.org | 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 < [ mailto:tim.jo...@mccarthy.co.nz | tim.jo...@mccarthy.co.nz ] > : BQ_BEGIN 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" < [ mailto:njbartl...@gmail.com | njbartl...@gmail.com ] > To: "OSGi Developer Mail List" < [ mailto:osgi-dev@mail.osgi.org | 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 BQ_BEGIN On 24 Jan 2017, at 20:42, Tim Jones < [ mailto:tim.jo...@mccarthy.co.nz | 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" < [ mailto:njbartl...@gmail.com | njbartl...@gmail.com ] > To: "OSGi Developer Mail List" < [ mailto:osgi-dev@mail.osgi.org | 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 BQ_BEGIN On 23 Jan 2017, at 06:26, Christian Schneider < [ mailto:ch...@die-schneider.net | 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 < [ mailto:tim.jo...@mccarthy.co.nz | tim.jo...@mccarthy.co.nz ] > : BQ_BEGIN 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 [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END -- -- Christian Schneider [ https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de | http://www.liquid-reality.de ] Open Source Architect [ https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com | http://www.talend.com ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END -- -- Christian Schneider [ https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de | http://www.liquid-reality.de ] Open Source Architect [ https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com | http://www.talend.com ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END -- [ http://www.liferay.com/web/raymond.auge/profile | Raymond Augé ] (@rotty3000) Senior Software Architect [ http://www.liferay.com/ | Liferay, Inc. ] (@Liferay) Board Member & EEG Co-Chair, [ http://osgi.org/ | OSGi Alliance ] (@OSGiAlliance) _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END -- [ http://www.liferay.com/web/raymond.auge/profile | Raymond Augé ] (@rotty3000) Senior Software Architect [ http://www.liferay.com/ | Liferay, Inc. ] (@Liferay) Board Member & EEG Co-Chair, [ http://osgi.org/ | OSGi Alliance ] (@OSGiAlliance) BQ_END -- [ http://www.liferay.com/web/raymond.auge/profile | Raymond Augé ] (@rotty3000) Senior Software Architect [ http://www.liferay.com/ | Liferay, Inc. ] (@Liferay) Board Member & EEG Co-Chair, [ http://osgi.org/ | OSGi Alliance ] (@OSGiAlliance) _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END -- [ http://www.liferay.com/web/raymond.auge/profile | Raymond Augé ] (@rotty3000) Senior Software Architect [ http://www.liferay.com/ | Liferay, Inc. ] (@Liferay) Board Member & EEG Co-Chair, [ http://osgi.org/ | OSGi Alliance ] (@OSGiAlliance) BQ_END -- [ http://www.liferay.com/web/raymond.auge/profile | Raymond Augé ] (@rotty3000) Senior Software Architect [ http://www.liferay.com/ | Liferay, Inc. ] (@Liferay) Board Member & EEG Co-Chair, [ http://osgi.org/ | OSGi Alliance ] (@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
