[jira] [Updated] (ARIES-1805) Blueprint core does not honor Java beans specification

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated ARIES-1805:
---
Summary: Blueprint core does not honor Java beans specification  (was: 
Blueprint core dose not honor Java beans specification)

> Blueprint core does not honor Java beans specification
> --
>
> Key: ARIES-1805
> URL: https://issues.apache.org/jira/browse/ARIES-1805
> Project: Aries
>  Issue Type: Bug
>  Components: Blueprint
>Affects Versions: blueprint-core-1.8.0
>Reporter: Andrea Tarocchi
>Assignee: Guillaume Nodet
>Priority: Major
>
> Aries blueprint core, to consider a property legit, checks that is and get 
> access methods are not present at the same time: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
>  specifically: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249
> looking at java bean specification: 
> http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
> it seems that both access methods ({{is}} and {{get}}) are allowed to be 
> present at the same time, in that case, the {{is}} has to be used:
> bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow 
> a getter method to match the pattern: public boolean is(); This 
> “is” method may be provided instead of a “get” 
> method, or it may be provided in addition to a “get” method. In 
> either case, if the “is” method is present for a boolean 
> property then we will use the “is” method to read the property 
> value.
> Should the Aries implementation be modified accordingly?
> I've provided a test case in this PR https://github.com/apache/aries/pull/85
> If possible,  would be nice to have this available to version {{1.8.0}} as 
> well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARIES-1808) ComponentDefinitionException message should contain actual class (interface) name instead of "ReferenceRecipe$ServiceProxyWrapper"

[Michael Vorburger (JIRA)]

Michael Vorburger created ARIES-1808:


 Summary: ComponentDefinitionException message should contain 
actual class (interface) name instead of "ReferenceRecipe$ServiceProxyWrapper"
 Key: ARIES-1808
 URL: https://issues.apache.org/jira/browse/ARIES-1808
 Project: Aries
  Issue Type: Bug
Reporter: Michael Vorburger


I made some mistake in looking up a  via an interface and then 
passing that id as an  to a  which expected a concrete class 
implementing that interface, and thought that kind error message could be a lot 
more helpful if it contained the contain actual class (interface) names it was 
about instead of (literally) "ReferenceRecipe$ServiceProxyWrapper" :
{noformat}
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to 
find a matching constructor on class 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataBrokerAdapter for 
arguments 
[org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@3be77953
 (class 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper), 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@333e9ff0
 (class 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper)] when 
instanciating bean tracingBindingDataBroker
org.osgi.service.blueprint.container.ComponentDefinitionException: 
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to 
find a matching constructor on class 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataBrokerAdapter for 
arguments 
[org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@3be77953
 (class 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper), 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper@333e9ff0
 (class 
org.apache.aries.blueprint.container.ReferenceRecipe$ServiceProxyWrapper)] when 
instanciating bean tracingBindingDataBroker
 at 
org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
 at 
org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
 at 
org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
 at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
 at 
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
 at 
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
 at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:704)
 at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:410)
 at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:275)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at 
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
 at 
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48){noformat}
 

https://git.opendaylight.org/gerrit/#/c/72530/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

REMINDER: Apache EU Roadshow 2018 in Berlin is less than 2 weeks away!

[sharan]

Hello Apache Supporters and Enthusiasts

This is a reminder that our Apache EU Roadshow in Berlin is less than 
two weeks away and we need your help to spread the word. Please let your 
work colleagues, friends and anyone interested in any attending know 
about our Apache EU Roadshow event.


We have a great schedule including tracks on Apache Tomcat, Apache Http 
Server, Microservices, Internet of Things (IoT) and Cloud Technologies. 
You can find more details at the link below:


https://s.apache.org/0hnG

Ticket prices will be going up on 8^th June 2018, so please make sure 
that you register soon if you want to beat the price increase. 
https://foss-backstage.de/tickets


Remember that registering for the Apache EU Roadshow also gives you 
access to FOSS Backstage so you can attend any talks and workshops from 
both conferences. And don’t forget that our Apache Lounge will be open 
throughout the whole conference as a place to meet up, hack and relax.


We look forward to seeing you in Berlin!

Thanks
Sharan Foga,  VP Apache Community Development

http://apachecon.com/
@apachecon

PLEASE NOTE: You are receiving this message because you are subscribed 
to a user@ or dev@ list of one or more Apache Software Foundation projects.

[jira] [Created] (ARIES-1807) SPI-Fly's weaving hook is subject to start ordering

[JIRA]

Raymond Augé created ARIES-1807:
---

 Summary: SPI-Fly's weaving hook is subject to start ordering
 Key: ARIES-1807
 URL: https://issues.apache.org/jira/browse/ARIES-1807
 Project: Aries
  Issue Type: Bug
  Components: SPI Fly
Reporter: Raymond Augé


SPI-Fly is subject to start ordering constraints. This is because weaving hooks 
are not retroactive in the framework, they only take effect at the moment they 
are registered. As such they do not operate on previous possible candiates.

It would be nice if SPI-Fly could trigger a refresh on already installed 
bundles such that weaving would take affect on them. This would eliminate the 
start ordering problem. Making this a configurable feature would also probably 
be a good idea.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARIES-1806) Support to create prototype scoped services

[JIRA]

Raymond Augé created ARIES-1806:
---

 Summary: Support to create prototype scoped services
 Key: ARIES-1806
 URL: https://issues.apache.org/jira/browse/ARIES-1806
 Project: Aries
  Issue Type: New Feature
  Components: SPI Fly
Reporter: Raymond Augé


It would be nice if one could specify that the type of service produced for the 
SPI type is prototype scoped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: recent Aries Proxy overzealous weaving

[Raymond Auge]

On Thu, May 31, 2018 at 11:59 AM, Timothy Ward 
wrote:

> > Can we tone it back a little? I'd recommend to make it not weave anything
> > by default!
>
> If you did that then proxy would be effectively disabled.
>

I get that... but right now if you drop Proxy into an existing system the
result is totally unpredictable. Proxy just goes along and weaves
everything in it's path causing catastrophic failures. This can't be an
acceptable default in my opinion.


>
> > On 30 May 2018, at 20:51, Raymond Auge  wrote:
> >
> > Hello all,
> >
> > Does someone know why Proxy is so aggressively weaving by default?
> >
> > It seems that the default opt-in is everything (except itself)
> >
> > public static final String WEAVING_ENABLED_CLASSES_DEFAULT = "*";
> >
> > with the default opt outs being only:
> >
> > public static final String WEAVING_DISABLED_CLASSES_DEFAULT =
> > "org.objectweb.asm.*,org.slf4j.*,org.apache.log4j.*,
> javax.*,ch.qos.logback.*";
> >
> > this has the tendency to blow stuff up.
> >
> > Can we tone it back a little? I'd recommend to make it not weave anything
> > by default!
> >
> > --
> > *Raymond Augé* 
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* 
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Assigned] (ARIES-1805) Blueprint core dose not honor Java beans specification

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet reassigned ARIES-1805:
--

Assignee: Guillaume Nodet

> Blueprint core dose not honor Java beans specification
> --
>
> Key: ARIES-1805
> URL: https://issues.apache.org/jira/browse/ARIES-1805
> Project: Aries
>  Issue Type: Bug
>  Components: Blueprint
>Affects Versions: blueprint-core-1.8.0
>Reporter: Andrea Tarocchi
>Assignee: Guillaume Nodet
>Priority: Major
>
> Aries blueprint core, to consider a property legit, checks that is and get 
> access methods are not present at the same time: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
>  specifically: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249
> looking at java bean specification: 
> http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
> it seems that both access methods ({{is}} and {{get}}) are allowed to be 
> present at the same time, in that case, the {{is}} has to be used:
> bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow 
> a getter method to match the pattern: public boolean is(); This 
> “is” method may be provided instead of a “get” 
> method, or it may be provided in addition to a “get” method. In 
> either case, if the “is” method is present for a boolean 
> property then we will use the “is” method to read the property 
> value.
> Should the Aries implementation be modified accordingly?
> I've provided a test case in this PR https://github.com/apache/aries/pull/85
> If possible,  would be nice to have this available to version {{1.8.0}} as 
> well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: recent Aries Proxy overzealous weaving

[Timothy Ward]

> Can we tone it back a little? I'd recommend to make it not weave anything
> by default!

If you did that then proxy would be effectively disabled.

> On 30 May 2018, at 20:51, Raymond Auge  wrote:
> 
> Hello all,
> 
> Does someone know why Proxy is so aggressively weaving by default?
> 
> It seems that the default opt-in is everything (except itself)
> 
> public static final String WEAVING_ENABLED_CLASSES_DEFAULT = "*";
> 
> with the default opt outs being only:
> 
> public static final String WEAVING_DISABLED_CLASSES_DEFAULT =
> "org.objectweb.asm.*,org.slf4j.*,org.apache.log4j.*,javax.*,ch.qos.logback.*";
> 
> this has the tendency to blow stuff up.
> 
> Can we tone it back a little? I'd recommend to make it not weave anything
> by default!
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Updated] (ARIES-1805) Blueprint core dose not honor Java beans specification

[Andrea Tarocchi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Tarocchi updated ARIES-1805:
---
Description: 
Aries blueprint core, to consider a property legit, checks that is and get 
access methods are not present at the same time: 
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
 specifically: 
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249

looking at java bean specification: 
http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
it seems that both access methods ({{is}} and {{get}}) are allowed to be 
present at the same time, in that case, the {{is}} has to be used:

bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow a 
getter method to match the pattern: public boolean is(); This 
“is” method may be provided instead of a “get” 
method, or it may be provided in addition to a “get” method. In 
either case, if the “is” method is present for a boolean property 
then we will use the “is” method to read the property value.

Should the Aries implementation be modified accordingly?

I've provided a test case in this PR https://github.com/apache/aries/pull/85

If possible,  would be nice to have this available to version {{1.8.0}} as well.


  was:
Aries blueprint core, to consider a property legit, checks that is and get 
access methods are not present at the same time: 
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
 specifically: 
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249

looking at java bean specification: 
http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
it seems that both access methods ({{is}} and {{get}}) are allowed to be 
present at the same time, in that case, the {{is}} has to be used:

bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow a 
getter method to match the pattern: public boolean is(); This 
“is” method may be provided instead of a “get” 
method, or it may be provided in addition to a “get” method. In 
either case, if the “is” method is present for a boolean property 
then we will use the “is” method to read the property value.

Should the Aries implementation b modified accordingly?




> Blueprint core dose not honor Java beans specification
> --
>
> Key: ARIES-1805
> URL: https://issues.apache.org/jira/browse/ARIES-1805
> Project: Aries
>  Issue Type: Bug
>  Components: Blueprint
>Affects Versions: blueprint-core-1.8.0
>Reporter: Andrea Tarocchi
>Priority: Major
>
> Aries blueprint core, to consider a property legit, checks that is and get 
> access methods are not present at the same time: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
>  specifically: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249
> looking at java bean specification: 
> http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
> it seems that both access methods ({{is}} and {{get}}) are allowed to be 
> present at the same time, in that case, the {{is}} has to be used:
> bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow 
> a getter method to match the pattern: public boolean is(); This 
> “is” method may be provided instead of a “get” 
> method, or it may be provided in addition to a “get” method. In 
> either case, if the “is” method is present for a boolean 
> property then we will use the “is” method to read the property 
> value.
> Should the Aries implementation be modified accordingly?
> I've provided a test case in this PR https://github.com/apache/aries/pull/85
> If possible,  would be nice to have this available to version {{1.8.0}} as 
> well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1805) Blueprint core dose not honor Java beans specification

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496703#comment-16496703
 ] 

ASF GitHub Bot commented on ARIES-1805:
---

GitHub user valdar opened a pull request:

https://github.com/apache/aries/pull/85

Modified ReflectionUtilsTest#testDuplicateGetter to reflect ARIES-1805

The test is not passing, is just as a reference for implementation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/valdar/aries ARIES-1805

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/aries/pull/85.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #85


commit e2d31d45331c47b42c86668d732b0e3ed48a1394
Author: Andrea Tarocchi 
Date:   2018-05-31T15:19:42Z

Modified ReflectionUtilsTest#testDuplicateGetter to reflect ARIES-1805




> Blueprint core dose not honor Java beans specification
> --
>
> Key: ARIES-1805
> URL: https://issues.apache.org/jira/browse/ARIES-1805
> Project: Aries
>  Issue Type: Bug
>  Components: Blueprint
>Affects Versions: blueprint-core-1.8.0
>Reporter: Andrea Tarocchi
>Priority: Major
>
> Aries blueprint core, to consider a property legit, checks that is and get 
> access methods are not present at the same time: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
>  specifically: 
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249
> looking at java bean specification: 
> http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
> it seems that both access methods ({{is}} and {{get}}) are allowed to be 
> present at the same time, in that case, the {{is}} has to be used:
> bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow 
> a getter method to match the pattern: public boolean is(); This 
> “is” method may be provided instead of a “get” 
> method, or it may be provided in addition to a “get” method. In 
> either case, if the “is” method is present for a boolean 
> property then we will use the “is” method to read the property 
> value.
> Should the Aries implementation b modified accordingly?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] aries pull request #85: Modified ReflectionUtilsTest#testDuplicateGetter to ...

[valdar]

GitHub user valdar opened a pull request:

https://github.com/apache/aries/pull/85

Modified ReflectionUtilsTest#testDuplicateGetter to reflect ARIES-1805

The test is not passing, is just as a reference for implementation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/valdar/aries ARIES-1805

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/aries/pull/85.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #85


commit e2d31d45331c47b42c86668d732b0e3ed48a1394
Author: Andrea Tarocchi 
Date:   2018-05-31T15:19:42Z

Modified ReflectionUtilsTest#testDuplicateGetter to reflect ARIES-1805




---

[jira] [Created] (ARIES-1805) Blueprint core dose not honor Java beans specification

[Andrea Tarocchi (JIRA)]

Andrea Tarocchi created ARIES-1805:
--

 Summary: Blueprint core dose not honor Java beans specification
 Key: ARIES-1805
 URL: https://issues.apache.org/jira/browse/ARIES-1805
 Project: Aries
  Issue Type: Bug
  Components: Blueprint
Affects Versions: blueprint-core-1.8.0
Reporter: Andrea Tarocchi


Aries blueprint core, to consider a property legit, checks that is and get 
access methods are not present at the same time: 
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L222-L255
 specifically: 
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L249

looking at java bean specification: 
http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1527758194_593d6e2c9336cf75e216a390c7b9
it seems that both access methods ({{is}} and {{get}}) are allowed to be 
present at the same time, in that case, the {{is}} has to be used:

bq. *8.3.2* Boolean properties In addition, for boolean properties, we allow a 
getter method to match the pattern: public boolean is(); This 
“is” method may be provided instead of a “get” 
method, or it may be provided in addition to a “get” method. In 
either case, if the “is” method is present for a boolean property 
then we will use the “is” method to read the property value.

Should the Aries implementation b modified accordingly?





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1804) Timeout due to connection loss in RSA fastbin provider?

[Johannes Utzig (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496456#comment-16496456
 ] 

Johannes Utzig commented on ARIES-1804:
---

Is the authentication service the only  remote service your application is 
calling?

If so, can you see from your server logs how much time has typically passed 
between the last successful and the first failing login?

It's possible that enabling TCP_KEEPALIVE on the socket would do the trick if 
it really stems from long inactivity (e.g. >2 hours).

> Timeout due to connection loss in RSA fastbin provider?
> ---
>
> Key: ARIES-1804
> URL: https://issues.apache.org/jira/browse/ARIES-1804
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.12.0
> Environment: Karaf 4.2.0
> RSA 1.12.0
> zookeeper 3.4.12
> java 1.8.0_172-b11
> RHEL 7.5
>Reporter: Alex Weirig
>Priority: Critical
> Attachments: AuthenticationServiceImpl.txt, LoginView.txt, 
> stacktrace.txt, zoo.cfg.txt
>
>
> Hello,
> I'm running two karaf (4.2.0) servers, one is running the frontend of my 
> application, the second one is running the backend.
> The backend services are published to 3 clustered zookeeper (3.4.12) servers. 
> In karaf I have deployed the following RSA features:
> karaf@appsrvtlk()> feature:list | grep rsa
> aries-rsa-core │ 1.12.0 │ │ Started │ aries-rsa-1.12.0 │
> aries-rsa-provider-tcp │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-provider-fastbin │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-local │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-config │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper-server │ 1.12.0 │ │ Uninstalled │ 
> aries-rsa-1.12.0 │
> When I start my karaf servers everything is working fine and my frontend can 
> call my backend service and gets the result. But after some time (I can't 
> figure out when) it seems that the connections between the karaf and 
> zookeeper gets lost and I'm getting a timeout when I call my remote service 
> eventhough all the servers (karaf and zookeepers) are still available and 
> responding. Exhibitor shows no apparent issues with the zookeepers.
> I have attached the 
>  * relevant parts of my LoginView UI where I declared the @Reference to my 
> service and where I call the remote service
>  * relevant parts of my AuthenticationService implementation that should be 
> called on the remote karaf
>  * the stacktrace that I'm getting on the frontend karaf when the timeout 
> occurs
>  * my zoo.cfg file
> From the stacktrace one can see that the LoginView has a non-null fastbin 
> proxy handler for the authentication service but that after 5 minutes a 
> timeout occurs and there is no line in the log that shows that the remote 
> service was actually called.
> Many thanks in advance for your support.
> Kind regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (ARIES-1804) Timeout due to connection loss in RSA fastbin provider?

[Johannes Utzig (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496321#comment-16496321
 ] 

Johannes Utzig edited comment on ARIES-1804 at 5/31/18 9:50 AM:


It doesn't sound like Zookeeper (or the connection to it) is the problem here.

Zookeeper is just used for sharing the information which services are exported, 
it is not used for the actual remote conmmunicatio.

If the zookeeper connection broke down, the remote services should get 
deregisted, not stop working.

To me this sounds like e.g. a firewall is dropping the connection at some 
point, maybe due to inactivity.

You should check the firewall settings/logs.

I don't know how long it takes you to reproduce this, but you could test the 
theory by invoking a simple remote service every minute or so, to see if the 
periodic traffic prevents the firewall from dropping the connection. If the 
authentication service works correctly after that, it definetly sounds like 
firewall/iptables


was (Author: j.utzig):
It doesn't sound like Zookeeper (or the connection to it) is the problem here.

Zookeeper is just used for sharing the information which services are exported, 
it is not used for the actual remote configuration.

If the zookeeper connection broke down, the remote services should get 
deregisted, not stop working.

To me this sounds like e.g. a firewall is dropping the connection at some 
point, maybe due to inactivity.

You should check the firewall settings/logs.

I don't know how long it takes you to reproduce this, but you could test the 
theory by invoking a simple remote service every minute or so, to see if the 
periodic traffic prevents the firewall from dropping the connection. If the 
authentication service works correctly after that, it definetly sounds like 
firewall/iptables

> Timeout due to connection loss in RSA fastbin provider?
> ---
>
> Key: ARIES-1804
> URL: https://issues.apache.org/jira/browse/ARIES-1804
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.12.0
> Environment: Karaf 4.2.0
> RSA 1.12.0
> zookeeper 3.4.12
> java 1.8.0_172-b11
> RHEL 7.5
>Reporter: Alex Weirig
>Priority: Critical
> Attachments: AuthenticationServiceImpl.txt, LoginView.txt, 
> stacktrace.txt, zoo.cfg.txt
>
>
> Hello,
> I'm running two karaf (4.2.0) servers, one is running the frontend of my 
> application, the second one is running the backend.
> The backend services are published to 3 clustered zookeeper (3.4.12) servers. 
> In karaf I have deployed the following RSA features:
> karaf@appsrvtlk()> feature:list | grep rsa
> aries-rsa-core │ 1.12.0 │ │ Started │ aries-rsa-1.12.0 │
> aries-rsa-provider-tcp │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-provider-fastbin │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-local │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-config │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper-server │ 1.12.0 │ │ Uninstalled │ 
> aries-rsa-1.12.0 │
> When I start my karaf servers everything is working fine and my frontend can 
> call my backend service and gets the result. But after some time (I can't 
> figure out when) it seems that the connections between the karaf and 
> zookeeper gets lost and I'm getting a timeout when I call my remote service 
> eventhough all the servers (karaf and zookeepers) are still available and 
> responding. Exhibitor shows no apparent issues with the zookeepers.
> I have attached the 
>  * relevant parts of my LoginView UI where I declared the @Reference to my 
> service and where I call the remote service
>  * relevant parts of my AuthenticationService implementation that should be 
> called on the remote karaf
>  * the stacktrace that I'm getting on the frontend karaf when the timeout 
> occurs
>  * my zoo.cfg file
> From the stacktrace one can see that the LoginView has a non-null fastbin 
> proxy handler for the authentication service but that after 5 minutes a 
> timeout occurs and there is no line in the log that shows that the remote 
> service was actually called.
> Many thanks in advance for your support.
> Kind regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1804) Timeout due to connection loss in RSA fastbin provider?

[Alex Weirig (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496307#comment-16496307
 ] 

Alex Weirig commented on ARIES-1804:


Hi Johannes,

thanks for the answer.

I obviously looked at the karaf logs on the 2nd karaf server and there is 
neither a stacktrace nor anything else since the service doesn't get called at 
all.

The service does a basic LDAP authentication so the response time is far less 
than a second, either auth is ok or not. There is no potentially long running 
process.

But again since the remote service is not called that can't be the problem. As 
you can see in the AuthenticationServiceImpl.txt I'm writing to the LogService 
as soon as the service is called and that never happens.

It seems that the "proxy connection" between the 2 karaf servers using 
zookeeper and fastbin stops working after several hours.

I also looked at zookeeper logs but can't find anything that could help me 
figure out what's happening.

I have a similar setup with 2 older karaf (4.1.1) servers but using the same 
zookeepers but running other services and there the problem does not occur.

So really strange ...

Alex

> Timeout due to connection loss in RSA fastbin provider?
> ---
>
> Key: ARIES-1804
> URL: https://issues.apache.org/jira/browse/ARIES-1804
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.12.0
> Environment: Karaf 4.2.0
> RSA 1.12.0
> zookeeper 3.4.12
> java 1.8.0_172-b11
> RHEL 7.5
>Reporter: Alex Weirig
>Priority: Critical
> Attachments: AuthenticationServiceImpl.txt, LoginView.txt, 
> stacktrace.txt, zoo.cfg.txt
>
>
> Hello,
> I'm running two karaf (4.2.0) servers, one is running the frontend of my 
> application, the second one is running the backend.
> The backend services are published to 3 clustered zookeeper (3.4.12) servers. 
> In karaf I have deployed the following RSA features:
> karaf@appsrvtlk()> feature:list | grep rsa
> aries-rsa-core │ 1.12.0 │ │ Started │ aries-rsa-1.12.0 │
> aries-rsa-provider-tcp │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-provider-fastbin │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-local │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-config │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper-server │ 1.12.0 │ │ Uninstalled │ 
> aries-rsa-1.12.0 │
> When I start my karaf servers everything is working fine and my frontend can 
> call my backend service and gets the result. But after some time (I can't 
> figure out when) it seems that the connections between the karaf and 
> zookeeper gets lost and I'm getting a timeout when I call my remote service 
> eventhough all the servers (karaf and zookeepers) are still available and 
> responding. Exhibitor shows no apparent issues with the zookeepers.
> I have attached the 
>  * relevant parts of my LoginView UI where I declared the @Reference to my 
> service and where I call the remote service
>  * relevant parts of my AuthenticationService implementation that should be 
> called on the remote karaf
>  * the stacktrace that I'm getting on the frontend karaf when the timeout 
> occurs
>  * my zoo.cfg file
> From the stacktrace one can see that the LoginView has a non-null fastbin 
> proxy handler for the authentication service but that after 5 minutes a 
> timeout occurs and there is no line in the log that shows that the remote 
> service was actually called.
> Many thanks in advance for your support.
> Kind regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (ARIES-1804) Timeout due to connection loss in RSA fastbin provider?

[Johannes Utzig (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496291#comment-16496291
 ] 

Johannes Utzig edited comment on ARIES-1804 at 5/31/18 9:08 AM:


You should have a look on the side that provides the service. Is there an 
exception? How long will the method execution take in worst case?

Sync remote calls are expected to execute fast so that they do not block the 
threads used for remote communication. If a sync call takes too long (default 
is 15s AFAIR) you will get a timeout like this.

For potentially long running calls, use async calls. To make the call async, 
have the method return either a Future, CompletableFuture or Promise.


was (Author: j.utzig):
You should have a look on the side that provides the service. Is there an 
exception? How  will the method execution take in worst case?

Sync remote calls are expected to execute fast so that they do not block the 
threads used for remote communication. If a sync call takes too long (default 
is 15s AFAIR) you will get a timeout like this.

For potentially long running calls, use async calls. To make the call async, 
have the method return either a Future, CompletableFuture or Promise.

> Timeout due to connection loss in RSA fastbin provider?
> ---
>
> Key: ARIES-1804
> URL: https://issues.apache.org/jira/browse/ARIES-1804
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.12.0
> Environment: Karaf 4.2.0
> RSA 1.12.0
> zookeeper 3.4.12
> java 1.8.0_172-b11
> RHEL 7.5
>Reporter: Alex Weirig
>Priority: Critical
> Attachments: AuthenticationServiceImpl.txt, LoginView.txt, 
> stacktrace.txt, zoo.cfg.txt
>
>
> Hello,
> I'm running two karaf (4.2.0) servers, one is running the frontend of my 
> application, the second one is running the backend.
> The backend services are published to 3 clustered zookeeper (3.4.12) servers. 
> In karaf I have deployed the following RSA features:
> karaf@appsrvtlk()> feature:list | grep rsa
> aries-rsa-core │ 1.12.0 │ │ Started │ aries-rsa-1.12.0 │
> aries-rsa-provider-tcp │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-provider-fastbin │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-local │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-config │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper-server │ 1.12.0 │ │ Uninstalled │ 
> aries-rsa-1.12.0 │
> When I start my karaf servers everything is working fine and my frontend can 
> call my backend service and gets the result. But after some time (I can't 
> figure out when) it seems that the connections between the karaf and 
> zookeeper gets lost and I'm getting a timeout when I call my remote service 
> eventhough all the servers (karaf and zookeepers) are still available and 
> responding. Exhibitor shows no apparent issues with the zookeepers.
> I have attached the 
>  * relevant parts of my LoginView UI where I declared the @Reference to my 
> service and where I call the remote service
>  * relevant parts of my AuthenticationService implementation that should be 
> called on the remote karaf
>  * the stacktrace that I'm getting on the frontend karaf when the timeout 
> occurs
>  * my zoo.cfg file
> From the stacktrace one can see that the LoginView has a non-null fastbin 
> proxy handler for the authentication service but that after 5 minutes a 
> timeout occurs and there is no line in the log that shows that the remote 
> service was actually called.
> Many thanks in advance for your support.
> Kind regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1804) Timeout due to connection loss in RSA fastbin provider?

[Johannes Utzig (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16496291#comment-16496291
 ] 

Johannes Utzig commented on ARIES-1804:
---

You should have a look on the side that provides the service. Is there an 
exception? How  will the method execution take in worst case?

Sync remote calls are expected to execute fast so that they do not block the 
threads used for remote communication. If a sync call takes too long (default 
is 15s AFAIR) you will get a timeout like this.

For potentially long running calls, use async calls. To make the call async, 
have the method return either a Future, CompletableFuture or Promise.

> Timeout due to connection loss in RSA fastbin provider?
> ---
>
> Key: ARIES-1804
> URL: https://issues.apache.org/jira/browse/ARIES-1804
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.12.0
> Environment: Karaf 4.2.0
> RSA 1.12.0
> zookeeper 3.4.12
> java 1.8.0_172-b11
> RHEL 7.5
>Reporter: Alex Weirig
>Priority: Critical
> Attachments: AuthenticationServiceImpl.txt, LoginView.txt, 
> stacktrace.txt, zoo.cfg.txt
>
>
> Hello,
> I'm running two karaf (4.2.0) servers, one is running the frontend of my 
> application, the second one is running the backend.
> The backend services are published to 3 clustered zookeeper (3.4.12) servers. 
> In karaf I have deployed the following RSA features:
> karaf@appsrvtlk()> feature:list | grep rsa
> aries-rsa-core │ 1.12.0 │ │ Started │ aries-rsa-1.12.0 │
> aries-rsa-provider-tcp │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-provider-fastbin │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-local │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-config │ 1.12.0 │ │ Uninstalled │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper │ 1.12.0 │ x │ Started │ aries-rsa-1.12.0 │
> aries-rsa-discovery-zookeeper-server │ 1.12.0 │ │ Uninstalled │ 
> aries-rsa-1.12.0 │
> When I start my karaf servers everything is working fine and my frontend can 
> call my backend service and gets the result. But after some time (I can't 
> figure out when) it seems that the connections between the karaf and 
> zookeeper gets lost and I'm getting a timeout when I call my remote service 
> eventhough all the servers (karaf and zookeepers) are still available and 
> responding. Exhibitor shows no apparent issues with the zookeepers.
> I have attached the 
>  * relevant parts of my LoginView UI where I declared the @Reference to my 
> service and where I call the remote service
>  * relevant parts of my AuthenticationService implementation that should be 
> called on the remote karaf
>  * the stacktrace that I'm getting on the frontend karaf when the timeout 
> occurs
>  * my zoo.cfg file
> From the stacktrace one can see that the LoginView has a non-null fastbin 
> proxy handler for the authentication service but that after 5 minutes a 
> timeout occurs and there is no line in the log that shows that the remote 
> service was actually called.
> Many thanks in advance for your support.
> Kind regards,
> Alex



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)