Re: Pax JDBC data sources are missing and never get resolved in a Karaf active/active configuration

[Christian Schneider]

Are the karaf instances on different machines?
If they are on different machines and you do not use cellar or specially
configured locking then both should come up completely independent from
each other.

Do you see anything in the log of the second instance when you stop the
first one? I wonder what could trigger the data source come up in this
moment.

Christian

2018-03-08 17:30 GMT+01:00 Matthew Zipay :

> Thanks for the quick replies.  With respect to Cellar, I should clarify
> that the Pax JDBC issue persists whether or not Cellar is involved (Cellar
> was a recent addition to the system, specifically to see if its explicit
> support for active/active would resolve the Pax JDBC issue - it did not).
>
> I have tried two variations:
> (1) Without Cellar, bring up both Karaf nodes without Karaf locking
> (karaf.lock=false). (i.e. "unsupported" active/active)
> (2) With Cellar, bring up both Karaf nodes without Karaf locking
> (karaf.lock=false). (i.e. "supported" active/active)
>
> In either scenario, the data sources only initialize on the *first* node
> that comes up.
>
> In either scenario, I can confirm that Pax JDBC bundles are started on
> both nodes:
>
> Node 1:
> 228 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Generic Driver Extender
> 229 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Config
> 230 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Pooling Support Base
> 270 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC MSSQL Driver Adapter
> 271 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Oracle Driver Adapter
> 272 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Pooling DBCP2
>
> Node 2:
> 228 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Generic Driver Extender
> 229 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Config
> 230 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Pooling Support Base
> 270 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC MSSQL Driver Adapter
> 271 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Oracle Driver Adapter
> 272 | Active  |  80 | 1.0.1  | OPS4J Pax
> JDBC Pooling DBCP2
>
> However, jdbc:ds-list only shows the initialized data sources on node 1;
> on node 2 *no* data sources are initialized, and I have multiple bundles in
> GracePeriod waiting for data sources that never show up. For example, on
> node 2:
>
> admin@root>diag 331
> SKU Resolution (331)
> ---
> Status: GracePeriod
> Blueprint
> 3/8/18 11:10 AM
> Missing dependencies:
> (&(dataSourceName=PRODUCTDS)(objectClass=javax.sql.DataSource))
>
>
> The "org.ops4j.datasource-PRODUCT.cfg" config file is present and
> identical on both nodes. I see the data source initialization occur in node
> 1's log, but nothing in node 2's log.  As soon as I bring down node 1, then
> I see the data sources on node 2 initialize.
>
> Could this have anything to do with ActiveMQ master/slave? That's the only
> constant here. It seems unlikely, but I'm out of ideas.
>
>
>
> On Thursday, March 8, 2018 at 2:32:39 AM UTC-5, Jean-Baptiste Onofré wrote:
>>
>> Hi,
>>
>> Cellar syncs the bundles and config on the cluster.
>>
>> By default, it doesn't sync "local" config (basically the etc/*.cfg
>> files). To do so, you have to enable the local listener in etc/
>> org.apache.karaf.cellar.groups.cfg.
>>
>> Else, you have to use cluster:config-property-set to create the config on
>> the cluster.
>>
>> Regards
>> JB
>>
>> On 03/08/2018 08:22 AM, Christian Schneider wrote:
>>
>> I am not experienced with cellar but generally I would expect that in an
>> active/active setup both machines start the same services.
>>
>> So first thing to check is if the pax-jdbc features and bundles are
>> active on the second node. If they are active you can check the log to see
>> if pax-jdbc reports that something is missing.
>>
>> When you describe that the datasources on the second machine come up when
>> the first machine goes down it sounds like you have setup something like a
>> master slave setup in cellar.
>>
>> Christian
>>
>> 2018-03-07 22:55 GMT+01:00 Matthew Zipay :
>>
>>> I really like the approach that Pax JDBC introduced for managing data
>>> sources, but I am running into an issue that may require me to abandon it
>>> if I can't get it resolved.
>>>
>>> My setup is as follows:
>>> ServiceMix 7.0.1 (Karaf 4.0.9) running on two nodes, clustered with
>>> Cellar (active/active). ActiveMQ is JDBC master/slave. Using Pax JDBC 1.0.1
>>> (config, pool, and oracle and mssql adapters).
>>>
>>> I have five (5) data sources configured for the various databases in use
>>> by this system. What I see is that the data sources are 

Re: PAX-EXAM - issue with Abstract classes in PerSuite reactor

[Matej Ferencak]

Oh, OK,

we did know about the Wiki page, but didn't take it seriously, because 
otherwise it worked pretty well for us until we ran into this issue.

Thanks anyway, I guess we'll try to go on using a workaround and see how 
far it gets us.

Regards,
Matej.

On Friday, March 9, 2018 at 1:32:01 PM UTC+1, laeubi wrote:
>
> This strategy (PerSuite) is only supported in Java EE, CDI and Web modes. 
>
> Also please read the warning about "PerSuite" here: 
>
>
> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263848/Reactor+Strategies
>  
>
> so it is very likely that it would produce inconsistent behaviour in 
> OSGi modes. 
>
> Am 09.03.2018 um 13:26 schrieb Matej Ferencak: 
> > Hi all, 
> > 
> > In our integration tests it’s common  to have an abstract class with 
> > @Test methods where common / boilerplate test code is executed, 
> > 
> > with subclasses which implement abstract methods for actual test 
> > specialization. 
> > 
> > We are also grouping tests in a suite, to minimize container startup 
> > overhead (we use Karaf). 
> > 
> > This means that practically one execution consists of a suite with one 
> > container running several probes, spread over several concrete class 
> > implementations of an abstract class with contains test methods. 
> > 
> > The problem we found, however, is that in such test suite, only one 
> > concrete subclass is ever executed (even though logs suggest otherwise), 
> > and all other subclasses are ignored. 
> > 
> > So the tests are executed N times (N = number of concrete classes), but 
> > each time only one (typically the last class in a suite) is actually 
> > probed (N times overall). 
> > 
> > The obvious workaround would be to use PerClass instead of PerSuite – 
> > but that would significantly increase our test execution time. 
> > 
> > Also, analysis of the bug showed that even this code path is not 100% 
> > „clean“. 
> > 
> > More detailed explanation including the test case can be found at: 
> > 
> > https://github.com/Traxpay/issues-paxexam-abstract-suite 
> > 
> > The project also includes a workaround which we are testing right now 
> > (see TraxpayProbeRunner.fillChildren() method). 
> > 
> > We can’t suggest an actual solution right now. 
> > 
> > Let me know if you need more info or if there is a better way to report 
> > this (Jira?). 
> > 
> > Thanks in advance, 
> > 
> > Matej. 
> > 
> > -- 
> > -- 
> > -- 
> > OPS4J - http://www.ops4j.org - op...@googlegroups.com  
> > 
> > --- 
> > You received this message because you are subscribed to the Google 
> > Groups "OPS4J" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to ops4j+un...@googlegroups.com  
> > . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PAX-EXAM - issue with Abstract classes in PerSuite reactor

['Christoph Läubrich' via OPS4J]

This strategy (PerSuite) is only supported in Java EE, CDI and Web modes.

Also please read the warning about "PerSuite" here:

https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263848/Reactor+Strategies

so it is very likely that it would produce inconsistent behaviour in 
OSGi modes.


Am 09.03.2018 um 13:26 schrieb Matej Ferencak:

Hi all,

In our integration tests it’s common  to have an abstract class with 
@Test methods where common / boilerplate test code is executed,


with subclasses which implement abstract methods for actual test 
specialization.


We are also grouping tests in a suite, to minimize container startup 
overhead (we use Karaf).


This means that practically one execution consists of a suite with one 
container running several probes, spread over several concrete class 
implementations of an abstract class with contains test methods.


The problem we found, however, is that in such test suite, only one 
concrete subclass is ever executed (even though logs suggest otherwise), 
and all other subclasses are ignored.


So the tests are executed N times (N = number of concrete classes), but 
each time only one (typically the last class in a suite) is actually 
probed (N times overall).


The obvious workaround would be to use PerClass instead of PerSuite – 
but that would significantly increase our test execution time.


Also, analysis of the bug showed that even this code path is not 100% 
„clean“.


More detailed explanation including the test case can be found at:

https://github.com/Traxpay/issues-paxexam-abstract-suite

The project also includes a workaround which we are testing right now 
(see TraxpayProbeRunner.fillChildren() method).


We can’t suggest an actual solution right now.

Let me know if you need more info or if there is a better way to report 
this (Jira?).


Thanks in advance,

Matej.

--
--
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

---
You received this message because you are subscribed to the Google 
Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to ops4j+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
--
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups "OPS4J" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PAX-EXAM - issue with Abstract classes in PerSuite reactor

[Matej Ferencak]

Hi all,

 

In our integration tests it’s common  to have an abstract class with @Test 
methods where common / boilerplate test code is executed,

with subclasses which implement abstract methods for actual test 
specialization.

 

We are also grouping tests in a suite, to minimize container startup 
overhead (we use Karaf).

This means that practically one execution consists of a suite with one 
container running several probes, spread over several concrete class 
implementations of an abstract class with contains test methods.

 

The problem we found, however, is that in such test suite, only one 
concrete subclass is ever executed (even though logs suggest otherwise), 
and all other subclasses are ignored.

So the tests are executed N times (N = number of concrete classes), but 
each time only one (typically the last class in a suite) is actually probed 
(N times overall).

 

The obvious workaround would be to use PerClass instead of PerSuite – but 
that would significantly increase our test execution time. 

Also, analysis of the bug showed that even this code path is not 100% 
„clean“.

 

More detailed explanation including the test case can be found at:

https://github.com/Traxpay/issues-paxexam-abstract-suite

 

The project also includes a workaround which we are testing right now (see 
TraxpayProbeRunner.fillChildren() method).

We can’t suggest an actual solution right now.

 

Let me know if you need more info or if there is a better way to report 
this (Jira?).

 

Thanks in advance,

Matej.

 

-- 
-- 
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.