Features Service lost its provision task

[Fabian Lange]

Hi,

I have a karaf instance which is starved for CPU, which might be helpful to
figure out how it could come to this:

A threaddump shows the following:

at sun.misc.Unsafe.park(boolean, long)
at java.util.concurrent.locks.LockSupport.park(java.lang.Object) (line:
175)
at java.util.concurrent.FutureTask.awaitDone(boolean, long) (line: 429)
at java.util.concurrent.FutureTask.get() (line: 191)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvisionInThread(java.util.Map,
java.util.Map, org.apache.karaf.features.internal.service.State,
java.util.EnumSet) (line: 1071)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.addRequirements(java.util.Map,
java.util.EnumSet) (line: 1014)

I checked the executor that is used here, and its thread is:

at sun.misc.Unsafe.park(boolean, long)at
java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long)
(line: 215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long)
(line: 2078)
at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take()
(line: 1093)
at
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take()
(line: 809)
at java.util.concurrent.ThreadPoolExecutor.getTask() (line: 1067)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
(line: 1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 617)
at java.lang.Thread.run() (line: 745)

So the thread is ready for work, the FeaturesService is waiting for the
work to complete.

Now it gets interesting. Looking at the heap dump, I can see the lambda
instance, and it is claimed to be on the stack of the executor thread

[image: Inline image 1]

But the thread dump disagrees.
The reason is, that this  pool-3-thread-1 exists twice!

So the get() is waiting forever, because the thread that is supposed to run
the callable is not running.

I am actually quite  puzzled how this could happen. Any ideas, suggestions
what I could look for?

What I think should happen in any case is that the doProvisionInThread sets
a timeout on the get() method, then potentially retires or other actions
could fix this situation.
Maybe the Features service was restarted? with bad timing? The stop()
method of the features service potentially should cancel/interrupt pending
tasks?

Fabian

--
Fabian Lange | Performance Expert
mobil: +49 (0) 160.3673393

codecentric AG | Hochstraße 11 | 42697 Solingen | Deutschland

Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

Re: [PROPOSAL] New pax project 'transx'

[Timothy Ward]

Hi Achim,

I am certain that that this is a conversation that has been had before, and 
that it would be better for any revisit of this discussion to be held between 
OPS4j and the Alliance rather than on the Karaf/Aries dev lists. I am also not 
an OSGi board representative, nor am I corporate officer of the OSGi Alliance, 
so I can’t speak on their behalf. Finally, I wasn’t part of any previous 
discussion between OPS4j and the OSGi Alliance about accepting implementations 
from OPS4j, so I do not know what any specific sticking points might have been.

I do know that in order for an “external” community to contribute reference 
implementations to the OSGi Alliance (which seems to be what we’re talking 
about here) there are rules about acceptable Open Source licences, levels of 
community diversity, legal IP governance and guarantees of originality for the 
code. There are probably other important requirements that I am not aware of. I 
know that Apache and Eclipse are examples of acceptable external communities 
which are regularly used to provide reference implementations, and that OPS4j 
is currently not on that list.

There may be very little for OPS4j to do to become another such community, or 
there may be some thornier problems that would need to be solved before that 
could be the case. If you want anything more specific I strongly recommend 
contacting the OSGi Alliance, either through a board member or the CTO. See 
https://www.osgi.org/about-us/board-officers/ for contact details.

Best Regards,

Tim


On 20 Jun 2017, at 12:12, Achim Nierbeck 
> wrote:

Hi Tim,

could you please elaborate on this a bit more?

On the other hand to maintain the openness of its standards the OSGi
Alliance must have a strict IP policy, one that prevents it from consuming
arbitrary code or IP from external sources. If OPS4j are able to get to a
compatible place contribution-wise then I'm sure you'd see a flow of work
in the other direction too.


especially the "If OPS4j are able to get to a compatible place
contribution-wise"

what in your view is missing for the OPS4j community to be regarded a
compatible place?

regards, Achim



2017-06-20 12:53 GMT+02:00 Timothy Ward 
>:

Hi Guillaume,

The OSGi Alliance is an open organisation, and a number of OPS4j
developers are already members via their companies. There is absolutely
nothing preventing them from getting involved with the Alliance, nor
preventing any non-members from joining.

On the other hand to maintain the openness of its standards the OSGi
Alliance must have a strict IP policy, one that prevents it from consuming
arbitrary code or IP from external sources. If OPS4j are able to get to a
compatible place contribution-wise then I'm sure you'd see a flow of work
in the other direction too.

As for Aries Tx Control - a Narayana based XA implementation would be a
great addition, as would JMS support.

Wrapping the Geronimo transaction manager is deliberate for three reasons:

* the javax.transaction package is toxic due to its split package in the
JRE. Hiding all of the JTA code allows the impl to work without system
packages being declared when launching the OSGi framework.

* by being Geronimo specific the implementation can offer last participant
support

* by being Geronimo specific the implementation can support XA recovery

This model gives a great level of functionality in an easy to access way
for users, and I would be keen to keep this option. A pluggable model is
possible, but would need to be done carefully to ensure that scopes could
cope with external parties "messing with" the transaction. It would also
lose the benefits described above, although neither of these things mean
that it would not be worth adding as an alternative implementation.

Finally - I am not sure why tx Control would have a dependency on pax jdbc
(other than as a source of DataSourceFactory services)? This sounds like it
would make the Aries project harder to configure and deploy, and I can't
immediately see what additional benefits it would provide. Can you clarify?

Regards,

Tim

Sent from my iPhone

On 20 Jun 2017, at 11:00, Guillaume Nodet 
> wrote:

2017-06-16 11:16 GMT+02:00 Richard Nicholson 
>:


Doesn’t this directly clash with OSGi Alliance Transaction Control
Specification work going on in Aries?

If so, wouldn’t it make more sense for this community to input into that
work rather than cause needless confusion / fragmentation?


Just a thought.


Yeah, I'm a bit skeptic about the relationship between the OPS4j
community
and the OSGi Alliance work.  It seems to always go in the same
direction...
i.e. the guys working at OPS4j should help working on the project defined
by the guys working at the OSGi Alliance.

That being said, the work in Aries is 

Re: [PROPOSAL] New pax project 'transx'

[Achim Nierbeck]

Hi Tim,

could you please elaborate on this a bit more?

On the other hand to maintain the openness of its standards the OSGi
> Alliance must have a strict IP policy, one that prevents it from consuming
> arbitrary code or IP from external sources. If OPS4j are able to get to a
> compatible place contribution-wise then I'm sure you'd see a flow of work
> in the other direction too.


especially the "If OPS4j are able to get to a compatible place
contribution-wise"

what in your view is missing for the OPS4j community to be regarded a
compatible place?

regards, Achim



2017-06-20 12:53 GMT+02:00 Timothy Ward :

> Hi Guillaume,
>
> The OSGi Alliance is an open organisation, and a number of OPS4j
> developers are already members via their companies. There is absolutely
> nothing preventing them from getting involved with the Alliance, nor
> preventing any non-members from joining.
>
> On the other hand to maintain the openness of its standards the OSGi
> Alliance must have a strict IP policy, one that prevents it from consuming
> arbitrary code or IP from external sources. If OPS4j are able to get to a
> compatible place contribution-wise then I'm sure you'd see a flow of work
> in the other direction too.
>
> As for Aries Tx Control - a Narayana based XA implementation would be a
> great addition, as would JMS support.
>
> Wrapping the Geronimo transaction manager is deliberate for three reasons:
>
> * the javax.transaction package is toxic due to its split package in the
> JRE. Hiding all of the JTA code allows the impl to work without system
> packages being declared when launching the OSGi framework.
>
> * by being Geronimo specific the implementation can offer last participant
> support
>
> * by being Geronimo specific the implementation can support XA recovery
>
> This model gives a great level of functionality in an easy to access way
> for users, and I would be keen to keep this option. A pluggable model is
> possible, but would need to be done carefully to ensure that scopes could
> cope with external parties "messing with" the transaction. It would also
> lose the benefits described above, although neither of these things mean
> that it would not be worth adding as an alternative implementation.
>
> Finally - I am not sure why tx Control would have a dependency on pax jdbc
> (other than as a source of DataSourceFactory services)? This sounds like it
> would make the Aries project harder to configure and deploy, and I can't
> immediately see what additional benefits it would provide. Can you clarify?
>
> Regards,
>
> Tim
>
> Sent from my iPhone
>
> > On 20 Jun 2017, at 11:00, Guillaume Nodet  wrote:
> >
> > 2017-06-16 11:16 GMT+02:00 Richard Nicholson :
> >
> >>
> >> Doesn’t this directly clash with OSGi Alliance Transaction Control
> >> Specification work going on in Aries?
> >>
> >> If so, wouldn’t it make more sense for this community to input into that
> >> work rather than cause needless confusion / fragmentation?
> >
> >
> >> Just a thought.
> >>
> >
> > Yeah, I'm a bit skeptic about the relationship between the OPS4j
> community
> > and the OSGi Alliance work.  It seems to always go in the same
> direction...
> > i.e. the guys working at OPS4j should help working on the project defined
> > by the guys working at the OSGi Alliance.
> >
> > That being said, the work in Aries is about defining a new programming
> > model for transactions.  That's something I'm not really interested in at
> > this point.  In addition, my initial goal is to have support for JMS +
> > Narayana and both aspects are not covered.  In particular, it does create
> > and wrap the geronimo TransactionManager instead of re-using an external
> > one (even the one defined in Aries Transaction for example).
> >
> > In theory, things should be layered.  For example, pax-jdbc provides a
> way
> > to expose DataSourceFactory objects in the OSGi registry.Imho,
> pooling
> > should be done at this level, as specified in the DataSourceFactory
> > interface.  So pooling inside aries-tx-control is irrelevant.
> >
> > This project is even at a lower level and I plan to integrate it below
> > pax-jdbc for the jdbc part.
> >
> > That said, I may have a look at aries-tx-control and see if I can replace
> > some of the code there to leverage pax-jdbc and pax-transx more to help
> > avoiding confusion and fragmentation.
> >
> >
> >>
> >>> On 15 Jun 2017, at 13:55, Toni Menzel  wrote:
> >>>
> >>> Sounds interesting!
> >>> Two comments:
> >>>
> >>>  - i find the whole space of "pooling resources" a not confusing and
> >> hard
> >>>  to find out what you actually really need. So, say once you know you
> >> want
> >>>  takaricp, which other bridges and matching configs do you need so that
> >> the
> >>>  DataSource proxy (for JDBC) appears in your Service Registry. Maybe
> >> it's
> >>>  just me not following bridge provider-projects like Aries 

Re: [PROPOSAL] New pax project 'transx'

[Timothy Ward]

Hi Christian

The Transaction Control API has no OSGi framework dependency, so a Java SE mode 
of operation would be possible (just like Aries blueprint no osgi). Possibly 
something worth exploring?

Tim

Sent from my iPhone

> On 20 Jun 2017, at 11:35, Christian Schneider  wrote:
> 
> Aries transaction control has a lot of good parts. Unfortunately though it is 
> an all or nothing solution.
> It works well if you directly depend on Aries transaction control in your 
> user code. Unfortunately this makes the code OSGi only. So this is not an 
> option for many projects like CXF or Camel.
> 
> The benefit of pax-jdbc-config and pax-jdbc-pool* ist that it provides a XA 
> ready DataSource that can be leveraged by code that is OSGi agnostic.
> 
> So I think there is a need for the same in the JMS space. So why not focus on 
> jms only and call the project pax-jms? In fact there already is such a 
> project that we could build on and extend for XA features.
> 
> Christian
> 
> 
>> On 16.06.2017 11:29, Timothy Ward wrote:
>> The Transaction Control project in Aries does have a pretty complete overlap 
>> with what’s being proposed here. There are already resource providers for 
>> JPA and JDBC which provide connection pooling, resource local transactions 
>> and XA transactions. It would be great to get some input into a JMS resource 
>> provider to extend the set of supported resource types.
>> 
>> The Aries TX control code already includes a base resource project for 
>> adding Resource providers which should help to ensure correct lifecycle 
>> management - I’d be happy to talk through that code in more detail. 
>> Contributing JMS support should therefore be a (relatively) simple process 
>> of providing the necessary JMS customisation much like with JDBC.
>> 
>> Happy to help,
>> 
>> Tim
>> 
>> 
>>> On 16 Jun 2017, at 10:20, Grzegorz Grzybek  wrote:
>>> 
>>> +1
>>> 
>>> Great about forking tranql - finally ;)
>>> 
>>> regards
>>> Grzegorz
>>> 
>>> 2017-06-16 11:16 GMT+02:00 Richard Nicholson :
>>> 
 Doesn’t this directly clash with OSGi Alliance Transaction Control
 Specification work going on in Aries?
 
 If so, wouldn’t it make more sense for this community to input into that
 work rather than cause needless confusion / fragmentation?
 
 Just a thought.
 
 
> On 15 Jun 2017, at 13:55, Toni Menzel  wrote:
> 
> Sounds interesting!
> Two comments:
> 
>  - i find the whole space of "pooling resources" a not confusing and
 hard
>  to find out what you actually really need. So, say once you know you
 want
>  takaricp, which other bridges and matching configs do you need so that
 the
>  DataSource proxy (for JDBC) appears in your Service Registry. Maybe
 it's
>  just me not following bridge provider-projects like Aries too closely.
>  Anything that makes setup simpler and offers a wider range of options
 is
>  highly welcome. (particularly in the OPS4J community, or how Bndtools
>  people say "P A X" ;)
>  - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the
>  Transx a bit alien. just an idea.
> 
> Thanks for your heads up, JB about karaf-boot. Was wondering what
 happened
> to it.
> 
> Toni
> 
> 
> On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck  
> wrote:
> 
>> Hi Guillaume,
>> 
>> sounds like a good idea to me, and the pax space like the perfect eco
>> system :)
>> 
>> regards, Achim
>> 
>> 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré :
>> 
>>> +1
>>> 
>>> It sounds like a good idea and definitely a good candidate for PAX.
>>> 
>>> By the way, on my side, I did good progress on:
>>> - karaf sample & new dev guide
>>> - some new updates on karaf-boot
>>> - ServiceMix APIMan for API/Service Discovery, Management, Gateway
>>> But I will send an update in separate threads.
>>> 
>>> Regards
>>> JB
>>> 
>>> 
 On 06/15/2017 09:57 AM, Guillaume Nodet wrote:
 
 I began to work on a small project which aims at providing support for
 pooled XA-enabled connections for JDBC and JMS.
 
 For JDBC, the problem was already solved in pax-jdbc by using either
 pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction
>> manager,
 and by using pax-jdbc-pool-narayana when using the Narayana
 transaction
 manager.
 
 However, there's absolutely no support for JMS.
 
 So what I've been doing is to reuse the geronimo JCA connector, make
 it
 independent on Geronimo TM and add support for Narayana, use a clone
 of
 the
 old tranql adapter for JDBC and rewrite a new JMS 2.0 

Re: [PROPOSAL] New pax project 'transx'

[Timothy Ward]

Hi Guillaume,

The OSGi Alliance is an open organisation, and a number of OPS4j developers are 
already members via their companies. There is absolutely nothing preventing 
them from getting involved with the Alliance, nor preventing any non-members 
from joining. 

On the other hand to maintain the openness of its standards the OSGi Alliance 
must have a strict IP policy, one that prevents it from consuming arbitrary 
code or IP from external sources. If OPS4j are able to get to a compatible 
place contribution-wise then I'm sure you'd see a flow of work in the other 
direction too.

As for Aries Tx Control - a Narayana based XA implementation would be a great 
addition, as would JMS support. 

Wrapping the Geronimo transaction manager is deliberate for three reasons:

* the javax.transaction package is toxic due to its split package in the JRE. 
Hiding all of the JTA code allows the impl to work without system packages 
being declared when launching the OSGi framework.

* by being Geronimo specific the implementation can offer last participant 
support

* by being Geronimo specific the implementation can support XA recovery

This model gives a great level of functionality in an easy to access way for 
users, and I would be keen to keep this option. A pluggable model is possible, 
but would need to be done carefully to ensure that scopes could cope with 
external parties "messing with" the transaction. It would also lose the 
benefits described above, although neither of these things mean that it would 
not be worth adding as an alternative implementation. 

Finally - I am not sure why tx Control would have a dependency on pax jdbc 
(other than as a source of DataSourceFactory services)? This sounds like it 
would make the Aries project harder to configure and deploy, and I can't 
immediately see what additional benefits it would provide. Can you clarify?

Regards,

Tim

Sent from my iPhone

> On 20 Jun 2017, at 11:00, Guillaume Nodet  wrote:
> 
> 2017-06-16 11:16 GMT+02:00 Richard Nicholson :
> 
>> 
>> Doesn’t this directly clash with OSGi Alliance Transaction Control
>> Specification work going on in Aries?
>> 
>> If so, wouldn’t it make more sense for this community to input into that
>> work rather than cause needless confusion / fragmentation?
> 
> 
>> Just a thought.
>> 
> 
> Yeah, I'm a bit skeptic about the relationship between the OPS4j community
> and the OSGi Alliance work.  It seems to always go in the same direction...
> i.e. the guys working at OPS4j should help working on the project defined
> by the guys working at the OSGi Alliance.
> 
> That being said, the work in Aries is about defining a new programming
> model for transactions.  That's something I'm not really interested in at
> this point.  In addition, my initial goal is to have support for JMS +
> Narayana and both aspects are not covered.  In particular, it does create
> and wrap the geronimo TransactionManager instead of re-using an external
> one (even the one defined in Aries Transaction for example).
> 
> In theory, things should be layered.  For example, pax-jdbc provides a way
> to expose DataSourceFactory objects in the OSGi registry.Imho, pooling
> should be done at this level, as specified in the DataSourceFactory
> interface.  So pooling inside aries-tx-control is irrelevant.
> 
> This project is even at a lower level and I plan to integrate it below
> pax-jdbc for the jdbc part.
> 
> That said, I may have a look at aries-tx-control and see if I can replace
> some of the code there to leverage pax-jdbc and pax-transx more to help
> avoiding confusion and fragmentation.
> 
> 
>> 
>>> On 15 Jun 2017, at 13:55, Toni Menzel  wrote:
>>> 
>>> Sounds interesting!
>>> Two comments:
>>> 
>>>  - i find the whole space of "pooling resources" a not confusing and
>> hard
>>>  to find out what you actually really need. So, say once you know you
>> want
>>>  takaricp, which other bridges and matching configs do you need so that
>> the
>>>  DataSource proxy (for JDBC) appears in your Service Registry. Maybe
>> it's
>>>  just me not following bridge provider-projects like Aries too closely.
>>>  Anything that makes setup simpler and offers a wider range of options
>> is
>>>  highly welcome. (particularly in the OPS4J community, or how Bndtools
>>>  people say "P A X" ;)
>>>  - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the
>>>  Transx a bit alien. just an idea.
>>> 
>>> Thanks for your heads up, JB about karaf-boot. Was wondering what
>> happened
>>> to it.
>>> 
>>> Toni
>>> 
>>> 
>>> On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck >> 
>>> wrote:
>>> 
 Hi Guillaume,
 
 sounds like a good idea to me, and the pax space like the perfect eco
 system :)
 
 regards, Achim
 
 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré :
 
> +1
> 
> It sounds like a good idea 

Re: [PROPOSAL] New pax project 'transx'

[Christian Schneider]

Aries transaction control has a lot of good parts. Unfortunately though 
it is an all or nothing solution.
It works well if you directly depend on Aries transaction control in 
your user code. Unfortunately this makes the code OSGi only. So this is 
not an option for many projects like CXF or Camel.


The benefit of pax-jdbc-config and pax-jdbc-pool* ist that it provides a 
XA ready DataSource that can be leveraged by code that is OSGi agnostic.


So I think there is a need for the same in the JMS space. So why not 
focus on jms only and call the project pax-jms? In fact there already is 
such a project that we could build on and extend for XA features.


Christian


On 16.06.2017 11:29, Timothy Ward wrote:

The Transaction Control project in Aries does have a pretty complete overlap 
with what’s being proposed here. There are already resource providers for JPA 
and JDBC which provide connection pooling, resource local transactions and XA 
transactions. It would be great to get some input into a JMS resource provider 
to extend the set of supported resource types.

The Aries TX control code already includes a base resource project for adding 
Resource providers which should help to ensure correct lifecycle management - 
I’d be happy to talk through that code in more detail. Contributing JMS support 
should therefore be a (relatively) simple process of providing the necessary 
JMS customisation much like with JDBC.

Happy to help,

Tim



On 16 Jun 2017, at 10:20, Grzegorz Grzybek  wrote:

+1

Great about forking tranql - finally ;)

regards
Grzegorz

2017-06-16 11:16 GMT+02:00 Richard Nicholson :


Doesn’t this directly clash with OSGi Alliance Transaction Control
Specification work going on in Aries?

If so, wouldn’t it make more sense for this community to input into that
work rather than cause needless confusion / fragmentation?

Just a thought.



On 15 Jun 2017, at 13:55, Toni Menzel  wrote:

Sounds interesting!
Two comments:

  - i find the whole space of "pooling resources" a not confusing and

hard

  to find out what you actually really need. So, say once you know you

want

  takaricp, which other bridges and matching configs do you need so that

the

  DataSource proxy (for JDBC) appears in your Service Registry. Maybe

it's

  just me not following bridge provider-projects like Aries too closely.
  Anything that makes setup simpler and offers a wider range of options

is

  highly welcome. (particularly in the OPS4J community, or how Bndtools
  people say "P A X" ;)
  - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the
  Transx a bit alien. just an idea.

Thanks for your heads up, JB about karaf-boot. Was wondering what

happened

to it.

Toni


On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck :


+1

It sounds like a good idea and definitely a good candidate for PAX.

By the way, on my side, I did good progress on:
- karaf sample & new dev guide
- some new updates on karaf-boot
- ServiceMix APIMan for API/Service Discovery, Management, Gateway
But I will send an update in separate threads.

Regards
JB


On 06/15/2017 09:57 AM, Guillaume Nodet wrote:


I began to work on a small project which aims at providing support for
pooled XA-enabled connections for JDBC and JMS.

For JDBC, the problem was already solved in pax-jdbc by using either
pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction

manager,

and by using pax-jdbc-pool-narayana when using the Narayana

transaction

manager.

However, there's absolutely no support for JMS.

So what I've been doing is to reuse the geronimo JCA connector, make

it

independent on Geronimo TM and add support for Narayana, use a clone

of

the
old tranql adapter for JDBC and rewrite a new JMS 2.0 compatible

adapter

for JMS.

It's not in a usable state yet, but I wanted to give an heads-up.
My plan is to make the pooling almost transparent in OSGi, and reuse

it

instead of the connection pooling I added to Karaf a few weeks ago

which

does not support XA or recovery:
  https://github.com/apache/karaf/tree/master/jms/pool
and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries and
pax-jdbc-pool-narayana.

The source code is currently available at:
  https://github.com/gnodet/org.ops4j.pax.transx


Cheers,



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com




--

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web 

Committer &

Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master





--
Christian 

Re: [PROPOSAL] New pax project 'transx'

[Guillaume Nodet]

2017-06-16 11:16 GMT+02:00 Richard Nicholson :

>
> Doesn’t this directly clash with OSGi Alliance Transaction Control
> Specification work going on in Aries?
>
> If so, wouldn’t it make more sense for this community to input into that
> work rather than cause needless confusion / fragmentation?


> Just a thought.
>

Yeah, I'm a bit skeptic about the relationship between the OPS4j community
and the OSGi Alliance work.  It seems to always go in the same direction...
i.e. the guys working at OPS4j should help working on the project defined
by the guys working at the OSGi Alliance.

That being said, the work in Aries is about defining a new programming
model for transactions.  That's something I'm not really interested in at
this point.  In addition, my initial goal is to have support for JMS +
Narayana and both aspects are not covered.  In particular, it does create
and wrap the geronimo TransactionManager instead of re-using an external
one (even the one defined in Aries Transaction for example).

In theory, things should be layered.  For example, pax-jdbc provides a way
to expose DataSourceFactory objects in the OSGi registry.Imho, pooling
should be done at this level, as specified in the DataSourceFactory
interface.  So pooling inside aries-tx-control is irrelevant.

This project is even at a lower level and I plan to integrate it below
pax-jdbc for the jdbc part.

That said, I may have a look at aries-tx-control and see if I can replace
some of the code there to leverage pax-jdbc and pax-transx more to help
avoiding confusion and fragmentation.


>
> > On 15 Jun 2017, at 13:55, Toni Menzel  wrote:
> >
> > Sounds interesting!
> > Two comments:
> >
> >   - i find the whole space of "pooling resources" a not confusing and
> hard
> >   to find out what you actually really need. So, say once you know you
> want
> >   takaricp, which other bridges and matching configs do you need so that
> the
> >   DataSource proxy (for JDBC) appears in your Service Registry. Maybe
> it's
> >   just me not following bridge provider-projects like Aries too closely.
> >   Anything that makes setup simpler and offers a wider range of options
> is
> >   highly welcome. (particularly in the OPS4J community, or how Bndtools
> >   people say "P A X" ;)
> >   - Any reason why this is not Pax Tx (org.ops4j.pax.tx) ?Find the
> >   Transx a bit alien. just an idea.
> >
> > Thanks for your heads up, JB about karaf-boot. Was wondering what
> happened
> > to it.
> >
> > Toni
> >
> >
> > On Thu, Jun 15, 2017 at 1:58 PM, Achim Nierbeck  >
> > wrote:
> >
> >> Hi Guillaume,
> >>
> >> sounds like a good idea to me, and the pax space like the perfect eco
> >> system :)
> >>
> >> regards, Achim
> >>
> >> 2017-06-15 10:20 GMT+02:00 Jean-Baptiste Onofré :
> >>
> >>> +1
> >>>
> >>> It sounds like a good idea and definitely a good candidate for PAX.
> >>>
> >>> By the way, on my side, I did good progress on:
> >>> - karaf sample & new dev guide
> >>> - some new updates on karaf-boot
> >>> - ServiceMix APIMan for API/Service Discovery, Management, Gateway
> >>> But I will send an update in separate threads.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 06/15/2017 09:57 AM, Guillaume Nodet wrote:
> >>>
>  I began to work on a small project which aims at providing support for
>  pooled XA-enabled connections for JDBC and JMS.
> 
>  For JDBC, the problem was already solved in pax-jdbc by using either
>  pax-jdbc-pool-aries when deploying the Aries/Geronimo transaction
> >> manager,
>  and by using pax-jdbc-pool-narayana when using the Narayana
> transaction
>  manager.
> 
>  However, there's absolutely no support for JMS.
> 
>  So what I've been doing is to reuse the geronimo JCA connector, make
> it
>  independent on Geronimo TM and add support for Narayana, use a clone
> of
>  the
>  old tranql adapter for JDBC and rewrite a new JMS 2.0 compatible
> adapter
>  for JMS.
> 
>  It's not in a usable state yet, but I wanted to give an heads-up.
>  My plan is to make the pooling almost transparent in OSGi, and reuse
> it
>  instead of the connection pooling I added to Karaf a few weeks ago
> which
>  does not support XA or recovery:
>    https://github.com/apache/karaf/tree/master/jms/pool
>  and maybe to plug it into pax-jdbc to replace pax-jdbc-pool-aries and
>  pax-jdbc-pool-narayana.
> 
>  The source code is currently available at:
>    https://github.com/gnodet/org.ops4j.pax.transx
> 
> 
>  Cheers,
> 
> 
> >>> --
> >>> Jean-Baptiste Onofré
> >>> jbono...@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> >>
> >>
> >> --
> >>
> >> Apache Member
> >> Apache Karaf  Committer & PMC
> >> OPS4J Pax Web 
> Committer &
> >>