Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...

[Milen Dyankov]

I ended up having:

→ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building osgi.enroute.examples.eval.bndrun 1.0.0-SNAPSHOT
[INFO]

[WARNING] The POM for
biz.aQute.bnd:bnd-export-maven-plugin:jar:3.4.0-SNAPSHOT is missing, no
dependency information available
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 0.109 s
[INFO] Finished at: 2016-10-12T00:26:21+02:00
[INFO] Final Memory: 7M/309M
[INFO]

[ERROR] Plugin biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
biz.aQute.bnd:bnd-export-maven-plugin:jar:3.4.0-SNAPSHOT -> [Help 1]
[ERROR]

after creating the bndrun sub-project. This is with maven 3.3.9. I had to
add


  
bnd-snapshots

https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/

default
  

to my parent POM to make it work.

Regards,
Milen

On Tue, Oct 11, 2016 at 4:23 PM, BJ Hargrave  wrote:

> > Btw. I wonder if we could use a command line option for maven to auto
> update the runbundles. So you could describe to first run the build with
> mvn install. It fails and then run again with the option to replace the
> runbundles. That would be a lot simpler than copy pasting them.
>
> We just added support like this to the gradle plugin. It has resolve.XXX
> tasks which run the resolver for the XXX.bndrun file and then replaces the
> -runbundles statement in that bndrun file.
>
> https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.
> gradle/src/aQute/bnd/gradle/BndPlugin.groovy#L451-L497
>
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>
>
>
> - Original message -
> From: Christian Schneider 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: OSGi Developer Mail List 
> Cc:
> Subject: Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...
> Date: Fri, Oct 7, 2016 2:20 PM
>
> Hi Peter,
>
> do you also provide the full source code of the finished project?
> I read most of the instructions and generally they look good but I think I
> personally would never try to recreate the whole project by hand by
> following the steps.
> I think most people would simply checkout the finished example and try and
> experiment with it while reading the sections of the tutorial.
>
> I also think the instructions for creating and adding the runbundles
> manually are quite tedious. I would rather leave the option to auto resolve
> on for the start and explain in a special section what the risks are and
> how to avoid these by "approving" the resolve manually like you describe
> now.
>
> Btw. I wonder if we could use a command line option for maven to auto
> update the runbundles. So you could describe to first run the build with
> mvn install. It fails and then run again with the option to replace the
> runbundles. That would be a lot simpler than copy pasting them.
>
> Christian
>
> On 06.10.2016 15:51, Peter Kriens wrote:
>
> I’ve created a tutorial for OSGi enRoute with Maven and vi. I am in need
> of some people that are willing to review this tutorial.
>
> The tutorial is at http://enroute.osgi.org/tutorial_eval/050-start.html
>
> You can find the Github source code at: https://github.com/osgi/
> osgi.enroute.site/tree/gh-pages/_tutorial_eval
>
> Please provide tool requests and issues or just mail me personally at
> peter.kri...@aqute.biz .
>
> Any help would be HIGHLY appreciated. Kind regards,
>
> Peter Kriens
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.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
>



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Promises 1.1 Draft

[Timothy Ward]

> On 11 Oct 2016, at 15:18, Simon Chemouil  wrote:
> 
> Hey Timothy,
> 
> Thanks for your answer! Final(?) comments inside :-)
> 
> 
>> It sounds as though you’re making pretty heavy use of Promises, which is
>> great to hear! I agree that an external method can be used to provide
>> timeouts, but the fact that users (including me) have felt it necessary
>> to create the method indicates that it should probably be part of the
>> core API. In general we have tried to keep the Promise
>> well-encapsulated, so adding timeout to the Promise interface felt most
>> consistent.
> 
> Well, I can certainly understand your point of view, and I'm grateful
> that you explained how you came to that solution.
> 
> As the ad said, "APIs are forever", and there's also this quote from Ben
> Franklin obviously referring to API design that comes to mind: "Those
> who sacrifice purity for practicality deserve neither" ;)
> 
> Jokes aside, a *big* selling point from the Promises API was the
> fluent/monadic writing style, especially over Guava's futures that are
> clumsy to code with in comparison. The fluent side of the Promises API
> is a big enabler and allows us to write non-blocking code almost
> transparently, so I understand why it is appealing to go that route for
> timeouting, which is also very much necessary.
> 
> I just wonder if there would not be a way to get the better of both
> worlds, for instance by keeping Promises as is with respect to threading
> (e.g, the new callback is not a problem), but having the timeout/delay
> facilities in a subtype, with its own deferred variant that takes a
> scheduler.
> 
> 
>> At the moment the behaviour of the OSGi-provided implementation works
>> well for you, as it creates no threads at all, however as of Promises
>> 1.1 this is likely to no longer be the case. This leaves you with a
>> decision point:
>> 
>>  * Stick with Promises 1.0 - if the new functionality is not needed in
>>your system then it is not mandatory to upgrade.
>>  * Use/Embed a specific implementation that gives you sufficient
>>control of the threading. If you couple to a specific implementation
>>(e.g. Apache Aries) then you can supply the Executor/Scheduler when
>>you instantiate the Promise
>>  * Write your own promise implementation to get the finest possible
>>control of the Promise lifecycle
>>  * Upgrade to the standard Promises 1.1, accepting that there will be
>>some threads created
> 
> Yep, I have to think it through. Back when I chose to go for OSGi
> Promises, I was ready to roll my own implementation/API but I found that
> it suited me. I wrote this mail today because I thought it was not too
> late for that feedback, thinking that if I have these requirements,
> others are bound to have the same eventually, especially as people are
> moving to non-blocking, message-based architectures, and try to optimize
> resource utilisation.

It’s definitely not too late for feedback - it’s one of the reasons that we try 
to keep RFC work out in the open (https://github.com/osgi/design 
) and to release draft specifications. I’m 
certain that this feedback will get discussed at the next OSGi meeting, and you 
should feel free to raise a bug against the draft specification in the OSGi 
bugzilla.

> 
>> As someone also uses Promises quite a lot in infrastructure services, I
>> can wholeheartedly recommend embedding a specific implementation if it
>> gives you the control that you need. OSGi is very good at handling
>> “substitutable” packages, i.e. providers that also import the API. An
>> example would be the Aries Async Service implementation - the Async
>> Service repackages the Aries Promise implementation, but imports the
>> Promise API. This means that whichever way round bundles resolve they
>> share the API packages, but it still allows Aries Async to use the Aries
>> Promise implementation, avoiding excessive thread creation. This is the
>> mechanism by which Felix SCR can use promises and co-exist in the same
>> runtime as another promises provider.
> 
> Do you mean rolling my own API that implements OSGi's Promise interface
> for compatibility, but exclusively using my variants of
> Deferred/Promises#resolved/Promises#failed to ensure I instantiate my
> own PromiseImpl?

What you’ve described is how you would provide your own Promises implementation 
(see also the Aries Promise implementation: 
https://github.com/apache/aries/tree/trunk/async/promise-api/src/main/java/org 
),
 and could be what you choose to do. I would, however, consider attempting to 
reuse the Aries implementation first (or even contributing to it). 

The Aries implementation is somewhat different from the default OSGi 
implementation, as it also provides org.apache.aries.async.promise.PromiseImpl 
as an exported type. This gives you the ability to directly control 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Peter Kriens]

These sides are -completely- disconnected and run by very different webmasters.

Kind regards,

Peter Kriens

> On 11 okt. 2016, at 16:28, Benson Margulies  wrote:
> 
> It's no longer dead AFAICT, so I doubt that I can be very precise here.
> 
> When the enRoute stuff first came up, several more or less front pages
> of osgi.org stopped displaying what they used to display, and
> displayed information about enRoute instead. I deleted my bookmarks,
> swore a bit, and moved on. As of today, the osgi.org front page is
> (back to?) displaying a front page, and searching in Google for
> 'ConfigurationListener' gets a hit for the 4.2 javadoc and no hit for
> the spec PDF, which is better than nothing.
> 
> 
> On Sat, Oct 8, 2016 at 9:48 AM, Peter Kriens  wrote:
>> What URL went dead?
>> 
>> 
>> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies 
>> wrote:
>>> 
>>> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
>>> wrote:
 
 On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
 
 On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
 wrote:
 
 
 On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
 
 On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
 wrote:
 
 
 
 On 07/10/16 21:04, Benson Margulies wrote:
 
 
 I am trying to express the following idea using DS:
 
 "If service X is provisioned in this container, do not activate me
 until it is activated and injected into me. If service X is not
 provisioned in this container, go ahead and activate me without it."
 
 
 
 how about making the dependency: static + greedy + optional.
 
 
 So, in practical terms, how greedy is 'greedy'? What's the behavior?
 
 
 Greedy means that if a service becomes available after your component is
 activated, then it will *always* be supplied to your component, even if
 that
 forces a restart of the component due to the reference having static
 policy.
 
 (It’s worth contrasting this with its opposite, reluctant: if you have
 an
 optional, static, reluctant reference then your component will NOT be
 restarted in order to give it a service that arrives after it is
 activated.
 That is, the component will continue to be bound to nothing even when a
 valid candidate service is available. While this makes perfect sense if
 you
 take the time to think it through, OSGi newbies tend to find it
 counterintuitive).
 
 By the way, with a greedy reference, you will also get re-bound when a
 service comes along that has a higher ranking than the one you are
 currently
 bound to. Again, this happens even if it requires restarting the
 component
 due to a static reference policy.
 
 All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
 Option”.
 
 
 I will do a better job of reading the specs when they are plain HTML
 files, searched by google, and not fenced with a mile legal verbiage.
 
 
 Please don’t misunderstand… when I give a reference to the spec it’s to
 back
 up what I’m saying so that you know it’s true, and to give you the
 opportunity to dig deeper. It is certainly NOT an accusation that you
 are
 being lazy for not already having found this information yourself.
>>> 
>>> OK, sorry about the snark. I have a certain amount of pent-up
>>> frustration, especially after a bunch of URLs went dead when the
>>> enRoute info went up. Thanks as always for the help.
>>> 
>>> 
 
 I would also like the specs to be more searchable. The PDFs look
 beautiful
 but that’s not so important unless they are in book form, and who wants
 to
 carry around a 1246 pages of Compendium?
 
 Neil
 
 
 
 
 
 Regards,
 Neil
 
 
 
 
 
 that way your component will get started always, and restarted once X
 becomes available.
 
 
 I fully appreciate that this concept is not compatible with the
 generally dynamic approach of OSGi in general, and declarative
 services in particular. However, I can think of a variation like:
 
 "I am willing to wait N seconds for service X. If it isn't there by
 then, activate me without it."
 
 I am taking a risk here -- it's always possible that some phenomenon
 would result in a delay of longer than N. But in my case, the startup
 properties of the containing application are such that this would be a
 low risk.
 
 Another possible approach would be to focus on provide/require
 capability. I don't know how I would get DS to pay attention, but it
 seems as if there's not enough information:
 
 Provide-Capability: 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

It's no longer dead AFAICT, so I doubt that I can be very precise here.

When the enRoute stuff first came up, several more or less front pages
of osgi.org stopped displaying what they used to display, and
displayed information about enRoute instead. I deleted my bookmarks,
swore a bit, and moved on. As of today, the osgi.org front page is
(back to?) displaying a front page, and searching in Google for
'ConfigurationListener' gets a hit for the 4.2 javadoc and no hit for
the spec PDF, which is better than nothing.


On Sat, Oct 8, 2016 at 9:48 AM, Peter Kriens  wrote:
> What URL went dead?
>
>
> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies 
> wrote:
>>
>> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
>> wrote:
>> >
>> > On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
>> >
>> > On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
>> > wrote:
>> >
>> >
>> > On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>> >
>> > On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
>> > wrote:
>> >
>> >
>> >
>> > On 07/10/16 21:04, Benson Margulies wrote:
>> >
>> >
>> > I am trying to express the following idea using DS:
>> >
>> >  "If service X is provisioned in this container, do not activate me
>> > until it is activated and injected into me. If service X is not
>> > provisioned in this container, go ahead and activate me without it."
>> >
>> >
>> >
>> > how about making the dependency: static + greedy + optional.
>> >
>> >
>> > So, in practical terms, how greedy is 'greedy'? What's the behavior?
>> >
>> >
>> > Greedy means that if a service becomes available after your component is
>> > activated, then it will *always* be supplied to your component, even if
>> > that
>> > forces a restart of the component due to the reference having static
>> > policy.
>> >
>> > (It’s worth contrasting this with its opposite, reluctant: if you have
>> > an
>> > optional, static, reluctant reference then your component will NOT be
>> > restarted in order to give it a service that arrives after it is
>> > activated.
>> > That is, the component will continue to be bound to nothing even when a
>> > valid candidate service is available. While this makes perfect sense if
>> > you
>> > take the time to think it through, OSGi newbies tend to find it
>> > counterintuitive).
>> >
>> > By the way, with a greedy reference, you will also get re-bound when a
>> > service comes along that has a higher ranking than the one you are
>> > currently
>> > bound to. Again, this happens even if it requires restarting the
>> > component
>> > due to a static reference policy.
>> >
>> > All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy
>> > Option”.
>> >
>> >
>> > I will do a better job of reading the specs when they are plain HTML
>> > files, searched by google, and not fenced with a mile legal verbiage.
>> >
>> >
>> > Please don’t misunderstand… when I give a reference to the spec it’s to
>> > back
>> > up what I’m saying so that you know it’s true, and to give you the
>> > opportunity to dig deeper. It is certainly NOT an accusation that you
>> > are
>> > being lazy for not already having found this information yourself.
>>
>> OK, sorry about the snark. I have a certain amount of pent-up
>> frustration, especially after a bunch of URLs went dead when the
>> enRoute info went up. Thanks as always for the help.
>>
>>
>> >
>> > I would also like the specs to be more searchable. The PDFs look
>> > beautiful
>> > but that’s not so important unless they are in book form, and who wants
>> > to
>> > carry around a 1246 pages of Compendium?
>> >
>> > Neil
>> >
>> >
>> >
>> >
>> >
>> > Regards,
>> > Neil
>> >
>> >
>> >
>> >
>> >
>> > that way your component will get started always, and restarted once X
>> > becomes available.
>> >
>> >
>> > I fully appreciate that this concept is not compatible with the
>> > generally dynamic approach of OSGi in general, and declarative
>> > services in particular. However, I can think of a variation like:
>> >
>> > "I am willing to wait N seconds for service X. If it isn't there by
>> > then, activate me without it."
>> >
>> > I am taking a risk here -- it's always possible that some phenomenon
>> > would result in a delay of longer than N. But in my case, the startup
>> > properties of the containing application are such that this would be a
>> > low risk.
>> >
>> > Another possible approach would be to focus on provide/require
>> > capability. I don't know how I would get DS to pay attention, but it
>> > seems as if there's not enough information:
>> >
>> > Provide-Capability: osgi.service;objectClass:List="com.basiste
>> > ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett
>> > eComponentService"
>> >
>> > Note that any properties are not represented here. So if the
>> > dependency is specific to some filter on properties, you can't use

Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...

[BJ Hargrave]

> Btw. I wonder if we could use a command line option for maven to auto update the runbundles. So you could describe to first run the build with mvn install. It fails and then run again with the option to replace the runbundles. That would be a lot simpler than copy pasting them. 
We just added support like this to the gradle plugin. It has resolve.XXX tasks which run the resolver for the XXX.bndrun file and then replaces the -runbundles statement in that bndrun file.
 
https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.gradle/src/aQute/bnd/gradle/BndPlugin.groovy#L451-L497
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Christian Schneider Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List Cc:Subject: Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...Date: Fri, Oct 7, 2016 2:20 PM 
Hi Peter,do you also provide the full source code of the finished project?I read most of the instructions and generally they look good but I think I personally would never try to recreate the whole project by hand by following the steps.I think most people would simply checkout the finished example and try and experiment with it while reading the sections of the tutorial.I also think the instructions for creating and adding the runbundles manually are quite tedious. I would rather leave the option to auto resolve on for the start and explain in a special section what the risks are and how to avoid these by "approving" the resolve manually like you describe now.Btw. I wonder if we could use a command line option for maven to auto update the runbundles. So you could describe to first run the build with mvn install. It fails and then run again with the option to replace the runbundles. That would be a lot simpler than copy pasting them.ChristianOn 06.10.2016 15:51, Peter Kriens wrote:
I’ve created a tutorial for OSGi enRoute with Maven and vi. I am in need of some people that are willing to review this tutorial.
 
The tutorial is at http://enroute.osgi.org/tutorial_eval/050-start.html
 
You can find the Github source code at: https://github.com/osgi/osgi.enroute.site/tree/gh-pages/_tutorial_eval
 
Please provide tool requests and issues or just mail me personally at peter.kri...@aqute.biz.
 
Any help would be HIGHLY appreciated. Kind regards,
 
Peter Kriens 

  

___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 

 
--Christian Schneiderhttp://www.liquid-reality.deOpen Source Architecthttp://www.talend.com
___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Promises 1.1 Draft

[Timothy Ward]

Hi Simon,

It sounds as though you’re making pretty heavy use of Promises, which is great 
to hear! I agree that an external method can be used to provide timeouts, but 
the fact that users (including me) have felt it necessary to create the method 
indicates that it should probably be part of the core API. In general we have 
tried to keep the Promise well-encapsulated, so adding timeout to the Promise 
interface felt most consistent.

In the application model that you describe you are correct that (as long as all 
your callbacks are non-blocking) the extra resource overhead associated with 
creating many executors/schedulers is wasteful. Any compliant Promise 
implementation will work for you, but there are definitely non-functional 
advantages to picking (or creating) a specific implementation.

At the moment the behaviour of the OSGi-provided implementation works well for 
you, as it creates no threads at all, however as of Promises 1.1 this is likely 
to no longer be the case. This leaves you with a decision point:

Stick with Promises 1.0 - if the new functionality is not needed in your system 
then it is not mandatory to upgrade.
Use/Embed a specific implementation that gives you sufficient control of the 
threading. If you couple to a specific implementation (e.g. Apache Aries) then 
you can supply the Executor/Scheduler when you instantiate the Promise
Write your own promise implementation to get the finest possible control of the 
Promise lifecycle
Upgrade to the standard Promises 1.1, accepting that there will be some threads 
created


As someone also uses Promises quite a lot in infrastructure services, I can 
wholeheartedly recommend embedding a specific implementation if it gives you 
the control that you need. OSGi is very good at handling “substitutable” 
packages, i.e. providers that also import the API. An example would be the 
Aries Async Service implementation - the Async Service repackages the Aries 
Promise implementation, but imports the Promise API. This means that whichever 
way round bundles resolve they share the API packages, but it still allows 
Aries Async to use the Aries Promise implementation, avoiding excessive thread 
creation. This is the mechanism by which Felix SCR can use promises and 
co-exist in the same runtime as another promises provider.

Regards,

Tim


> On 11 Oct 2016, at 12:31, Simon Chemouil  wrote:
> 
> Hi Timothy,
> 
> Thanks for your answer. Comments inlined.
> 
> [snip]
>> occur if the provider of the promise is mis-coded, or simply if the
>> triggering event never occurs. Timing out is usually the right thing to
>> do in these situations, so adding a primitive for that to the Promise
>> was made a target for Promises 1.1.
> 
> I agree, however this method can also be external. We have this method
> in our code base, on a separate service:
> 
>  Promise timeLimit(Promise promise, long delay, TimeUnit unit)
> 
> So while I understand it is practical to have as a fluent method on the
> Promise interface, it's not strictly required as a primitive.
> 
>> Updating the Apache Aries Async project is on my TODO list, I should
>> have it done in the next couple of weeks.
> 
> Great!
> 
>> As per the Promises specification, the method must not block. The rest
>> is down to the implementation of the promise - it would be perfectly
>> valid (although wasteful) to create a Timer, or a
>> ScheduledExecutorService inside each Promise. My plan in Aries is to
>> share the ScheduledExecutor where possible (i.e. in chained promises, or
>> promises created by the Async Service)
> 
> That is what I supposed. My main gripe with this approach is that
> Executors are holding system resources (threads) and I prefer designs
> that encapsulate such resources in services with a well-defined
> lifecycle. The sharing design still relies on automatic garbage
> collection. When trying to limit the number of threads in the JVM, I
> often end up chasing classes that spawn some. I am very fond of
> future/promises and I have been using the OSGi API a lot, so I am not
> sure of I feel about that change.
> 
> 
>> Non-blocking behaviour is required by the specification, but the
>> threading that you describe is the behaviour of one implementation. The
>> Promises specification purposefully does not define which thread is used
>> to run the callback. Apache Aries *always* uses a separate thread to run
>> callbacks, even in 1.0. This threading model gives a much greater scope
>> for optimisation when using the Async Service or Remote Services.
> 
> I don't use Async Service (because my services are designed to be async,
> and all return Promises on methods that do side-effects), or the Remote
> service (for other reasons). So I don't really know which optimisations
> this allows, but I guess it has to do with protecting these services
> against blocking user code.
> 
> In my case, I have a work stealing executor pool (as a service) running
> all non-blocking code, 

Re: [osgi-dev] OSGi enRoute Maven Testers wanted ...

[erwindl0]

I have done the complete tutorial, following all the steps in detail 
(yep even using vi!).


It's a great way to learn some basic things about the enroute/bnd 
way-of-working, combined with mvn pom setup.

Most importantly : everything works as described from the first try.
(I did have one temporary mvn issue due to its untransparent caching of 
snapshot artifacts, but that was a local issue on my setup)


So thanks Peter for another great contribution for the OSGi community!

cheers
erwin

Op 10/6/2016 om 4:38 PM schreef Peter Kriens:
Then just create issues on the OSGi enRoute site 
https://github.com/osgi/osgi.enroute.site 
. This will keep it nicely 
focused but visible to all. I’d like to get the most embarrassing 
errors out without looking like a fool on this forum but if there are 
more fundamental things then feel free to discuss it here.


You can also submit PRs with inline comments.

Kind regards,

Peter Kriens


On 6 okt. 2016, at 16:16, Milen Dyankov > wrote:


Peter,

can we discuss this here or it needs to go to your e-mail?
I mean it would be nice to discuss this in a place where people can 
follow even if they don't have the time to contribute themselves.


Best,
Milen

On Thu, Oct 6, 2016 at 4:06 PM, erwindl0 > wrote:


Peter,

I would like to try this out.

What is the test/review period you've planned for this? Is it ok
between now and mid November for instance?

regards
erwin

Op 10/6/2016 om 3:51 PM schreef Peter Kriens:

I’ve created a tutorial for OSGi enRoute with Maven and vi. I am
in need of some people that are willing to review this tutorial.

The tutorial is at
http://enroute.osgi.org/tutorial_eval/050-start.html


You can find the Github source code at:
https://github.com/osgi/osgi.enroute.site/tree/gh-pages/_tutorial_eval


Please provide tool requests and issues or just mail me
personally at peter.kri...@aqute.biz
.

Any help would be HIGHLY appreciated. Kind regards,

Peter Kriens


___
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
 


--
http://about.me/milen
___ 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

Re: [osgi-dev] Promises 1.1 Draft

[Simon Chemouil]

Hi Timothy,

Thanks for your answer. Comments inlined.

[snip]
> occur if the provider of the promise is mis-coded, or simply if the
> triggering event never occurs. Timing out is usually the right thing to
> do in these situations, so adding a primitive for that to the Promise
> was made a target for Promises 1.1.

I agree, however this method can also be external. We have this method
in our code base, on a separate service:

 Promise timeLimit(Promise promise, long delay, TimeUnit unit)

So while I understand it is practical to have as a fluent method on the
Promise interface, it's not strictly required as a primitive.

> Updating the Apache Aries Async project is on my TODO list, I should
> have it done in the next couple of weeks.

Great!

> As per the Promises specification, the method must not block. The rest
> is down to the implementation of the promise - it would be perfectly
> valid (although wasteful) to create a Timer, or a
> ScheduledExecutorService inside each Promise. My plan in Aries is to
> share the ScheduledExecutor where possible (i.e. in chained promises, or
> promises created by the Async Service)

That is what I supposed. My main gripe with this approach is that
Executors are holding system resources (threads) and I prefer designs
that encapsulate such resources in services with a well-defined
lifecycle. The sharing design still relies on automatic garbage
collection. When trying to limit the number of threads in the JVM, I
often end up chasing classes that spawn some. I am very fond of
future/promises and I have been using the OSGi API a lot, so I am not
sure of I feel about that change.


> Non-blocking behaviour is required by the specification, but the
> threading that you describe is the behaviour of one implementation. The
> Promises specification purposefully does not define which thread is used
> to run the callback. Apache Aries *always* uses a separate thread to run
> callbacks, even in 1.0. This threading model gives a much greater scope
> for optimisation when using the Async Service or Remote Services.

I don't use Async Service (because my services are designed to be async,
and all return Promises on methods that do side-effects), or the Remote
service (for other reasons). So I don't really know which optimisations
this allows, but I guess it has to do with protecting these services
against blocking user code.

In my case, I have a work stealing executor pool (as a service) running
all non-blocking code, and service to create custom pools for blocking
code (mostly because of blocking system calls such as mmap() or blocking
APIs such as JDBC).

In that setting, I believe spawning threads for callbacks is more
costly. The callbacks are already running by design in the right
non-blocking dispatcher, with the appropriate size, and little
thread/stack allocation cost (because it's already up and running).

I decided to go with the Promise API partly in part because it was
cleanly separate from threading. The "reference" Promise implementation
runs callbacks in the resolving thread, so it's perfect in my situation.

However, the timeout/delay design prevents me from doing that, short of
writing my own PromiseImpl implementation that either takes a Scheduler
as a parameter (and maybe redefine Deferred as well!), or resort to do a
service lookup for my scheduler when those methods are called (which I'd
rather not).

Also, using a custom org.osgi.promise implementation is a bit convoluted
(because of bundles such as Felix SCR already exporting a version, and
because it forces to order bundle resolution), so I'd be happy to avoid
doing so.


> I hope this helps,

It does, a lot! You answered my question exactly. Please treat my
comments above as feedback from a happy user :).

Thanks for the great work you do. Looking forward to playing PushStreams
as well.

Simon
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Promises 1.1 Draft

[Timothy Ward]

Hi Simon,


> On 11 Oct 2016, at 10:58, Simon Chemouil  wrote:
> 
> Hi,
> 
> I had a look at the recently published Compendium R7 draft.
> 
> I noticed the Promise interface has, among other changes, two new methods:
> * public Promise timeout(long milliseconds)
> * public Promise delay(long milliseconds)
> 
> (I somehow suppose these are also used by the new PushStream API)


Actually they aren’t (although the PushStream has similar timeout 
capabilities). These methods are being added because there is a need for the 
behaviour. As Promises have become more widely used a common problem has been 
“what do you do when a promise doesn’t resolve?”. This can occur if the 
provider of the promise is mis-coded, or simply if the triggering event never 
occurs. Timing out is usually the right thing to do in these situations, so 
adding a primitive for that to the Promise was made a target for Promises 1.1.

A good example is when you have a Promise representing the shutdown of an 
internal component. You call shutdown and then do some other things (or even 
return for the time being) and want to do more shutdown/cleanup when the 
Promise resolves. If the internal component hangs then you will never get a 
callback to do that further work. In this case you probably still want the 
Promise to trigger so that you can log/kill/recover in some way.


> Is there any provisional reference implementation publicly available
> anywhere?

Updating the Apache Aries Async project is on my TODO list, I should have it 
done in the next couple of weeks.


> I suppose any sane implementation of these would be non-blocking, and as
> far as I can see a good way to implement them is to use a Scheduler, but
> these methods don't take a Scheduler as a parameter, and I'm left
> wondering whether I'm missing something obvious, whether the default
> implementation is blocking, or if it's getting a scheduler from
> somewhere (or worse, constructing one or using a Timer), and if so,
> where from :)

As per the Promises specification, the method must not block. The rest is down 
to the implementation of the promise - it would be perfectly valid (although 
wasteful) to create a Timer, or a ScheduledExecutorService inside each Promise. 
My plan in Aries is to share the ScheduledExecutor where possible (i.e. in 
chained promises, or promises created by the Async Service)

> 
> Up to Promises 1.0, promises run in whatever thread we supply: either
> the calling thread or a callback thread, and all methods are
> non-blocking. Will this change with 1.1?

Non-blocking behaviour is required by the specification, but the threading that 
you describe is the behaviour of one implementation. The Promises specification 
purposefully does not define which thread is used to run the callback. Apache 
Aries always uses a separate thread to run callbacks, even in 1.0. This 
threading model gives a much greater scope for optimisation when using the 
Async Service or Remote Services.

Whilst the thread which executes a callback is not defined, the specification 
does guarantee strict happens-before relationships between a Promise resolving 
and callback execution. This ensures threading correctness where Promises are 
used.

I hope this helps,

Tim Ward

OSGi IoT Expert Group Chair
tim.w...@paremus.com

> 
> Thanks for pointers,
> 
> Simon
> ___
> 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-dev] Promises 1.1 Draft

[Simon Chemouil]

Hi,

I had a look at the recently published Compendium R7 draft.

I noticed the Promise interface has, among other changes, two new methods:
* public Promise timeout(long milliseconds)
* public Promise delay(long milliseconds)

(I somehow suppose these are also used by the new PushStream API)

Is there any provisional reference implementation publicly available
anywhere?

I suppose any sane implementation of these would be non-blocking, and as
far as I can see a good way to implement them is to use a Scheduler, but
these methods don't take a Scheduler as a parameter, and I'm left
wondering whether I'm missing something obvious, whether the default
implementation is blocking, or if it's getting a scheduler from
somewhere (or worse, constructing one or using a Timer), and if so,
where from :)

Up to Promises 1.0, promises run in whatever thread we supply: either
the calling thread or a callback thread, and all methods are
non-blocking. Will this change with 1.1?

Thanks for pointers,

Simon
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev