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

2018-06-01 Thread Johannes Utzig (JIRA)


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

Johannes Utzig commented on ARIES-1804:
---

I take it this was the first invocation?

*2018-06-01T16:00:00,*

And then it worked successfully in 5 minutes intevals until 16:30:00?

Would this match with the observations you've had before?

30 minutes is an awefully even amount of time, so to me it still sounds like a 
router or firewall that closes long running tcp connections.

> 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?

2018-05-31 Thread 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?

2018-05-31 Thread 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] [Comment Edited] (ARIES-1804) Timeout due to connection loss in RSA fastbin provider?

2018-05-31 Thread 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?

2018-05-31 Thread 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)


[jira] [Resolved] (ARIES-1759) Fastbin fails to bind if a configuration exists with the same port

2017-11-20 Thread Johannes Utzig (JIRA)

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

Johannes Utzig resolved ARIES-1759.
---
   Resolution: Fixed
Fix Version/s: rsa-1.12.0

> Fastbin fails to bind if a configuration exists with the same port
> --
>
> Key: ARIES-1759
> URL: https://issues.apache.org/jira/browse/ARIES-1759
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.10.0
>Reporter: Joao Assuncao
>Assignee: Johannes Utzig
> Fix For: rsa-1.12.0
>
>
> When Fastbin starts it binds to port 2543 even if no configuration exists. If 
> a configuration exists, it will reconfigure but won't wait for the previous 
> socket to unbind. In most cases it will fail to bind the second time.
> The workaround is to use in the configuration other port than the default one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (ARIES-1759) Fastbin fails to bind if a configuration exists with the same port

2017-11-20 Thread Johannes Utzig (JIRA)

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

Johannes Utzig reassigned ARIES-1759:
-

Assignee: Johannes Utzig

> Fastbin fails to bind if a configuration exists with the same port
> --
>
> Key: ARIES-1759
> URL: https://issues.apache.org/jira/browse/ARIES-1759
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.10.0
>Reporter: Joao Assuncao
>Assignee: Johannes Utzig
>
> When Fastbin starts it binds to port 2543 even if no configuration exists. If 
> a configuration exists, it will reconfigure but won't wait for the previous 
> socket to unbind. In most cases it will fail to bind the second time.
> The workaround is to use in the configuration other port than the default one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (ARIES-1713) TopologyManagerExport fails for multiple interfaces

2017-04-11 Thread Johannes Utzig (JIRA)

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

Johannes Utzig resolved ARIES-1713.
---
   Resolution: Fixed
Fix Version/s: rsa-1.11.0

> TopologyManagerExport fails for multiple interfaces
> ---
>
> Key: ARIES-1713
> URL: https://issues.apache.org/jira/browse/ARIES-1713
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.10.0
>Reporter: Johannes Utzig
>Assignee: Johannes Utzig
> Fix For: rsa-1.11.0
>
>
> When a remote service exports more than one interface there is a class cast 
> exception in TopologyManagerExport#shouldExport



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (ARIES-1714) fastbin long running (future) calls sometimes fail

2017-04-11 Thread Johannes Utzig (JIRA)

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

Johannes Utzig resolved ARIES-1714.
---
   Resolution: Fixed
Fix Version/s: rsa-1.11.0

> fastbin long running (future) calls sometimes fail
> --
>
> Key: ARIES-1714
> URL: https://issues.apache.org/jira/browse/ARIES-1714
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.10.0
>Reporter: Johannes Utzig
>Assignee: Johannes Utzig
> Fix For: rsa-1.11.0
>
>
> There is an eviction timeout in fastbins transport pool that can cause long 
> running remote calls (future based) to fail if no other invocations are sent 
> through the same transport for a while.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (ARIES-1714) fastbin long running (future) calls sometimes fail

2017-04-11 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1714:
-

 Summary: fastbin long running (future) calls sometimes fail
 Key: ARIES-1714
 URL: https://issues.apache.org/jira/browse/ARIES-1714
 Project: Aries
  Issue Type: Bug
  Components: Remote Service Admin
Affects Versions: rsa-1.10.0
Reporter: Johannes Utzig
Assignee: Johannes Utzig


There is an eviction timeout in fastbins transport pool that can cause long 
running remote calls (future based) to fail if no other invocations are sent 
through the same transport for a while.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (ARIES-1713) TopologyManagerExport fails for multiple interfaces

2017-04-11 Thread Johannes Utzig (JIRA)

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

Johannes Utzig reassigned ARIES-1713:
-

Assignee: Johannes Utzig

> TopologyManagerExport fails for multiple interfaces
> ---
>
> Key: ARIES-1713
> URL: https://issues.apache.org/jira/browse/ARIES-1713
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.10.0
>Reporter: Johannes Utzig
>Assignee: Johannes Utzig
>
> When a remote service exports more than one interface there is a class cast 
> exception in TopologyManagerExport#shouldExport



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (ARIES-1632) fastbin does not throw an error for unknown services

2016-11-21 Thread Johannes Utzig (JIRA)

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

Johannes Utzig resolved ARIES-1632.
---
   Resolution: Fixed
Fix Version/s: rsa-1.10.0

> fastbin does not throw an error for unknown services
> 
>
> Key: ARIES-1632
> URL: https://issues.apache.org/jira/browse/ARIES-1632
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Johannes Utzig
>Assignee: Johannes Utzig
> Fix For: rsa-1.10.0
>
>
> When the client invokes a service that is not known to the server, the 
> request is silently dropped.
> This is especially problematic if the client does an async call with futures. 
> There will never be a reply, therefore the client thread could hang 
> indefinitely.
> If a service id is unknown to the server, it should throw a ServiceException 
> early on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (ARIES-1632) fastbin does not throw an error for unknown services

2016-11-17 Thread Johannes Utzig (JIRA)

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

Johannes Utzig reassigned ARIES-1632:
-

Assignee: Johannes Utzig

> fastbin does not throw an error for unknown services
> 
>
> Key: ARIES-1632
> URL: https://issues.apache.org/jira/browse/ARIES-1632
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Johannes Utzig
>Assignee: Johannes Utzig
>
> When the client invokes a service that is not known to the server, the 
> request is silently dropped.
> This is especially problematic if the client does an async call with futures. 
> There will never be a reply, therefore the client thread could hang 
> indefinitely.
> If a service id is unknown to the server, it should throw a ServiceException 
> early on.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1587) Support streams in fastbin

2016-09-01 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1587:
---

created a pull request:
https://github.com/apache/aries-rsa/pull/14

> Support streams in fastbin
> --
>
> Key: ARIES-1587
> URL: https://issues.apache.org/jira/browse/ARIES-1587
> Project: Aries
>  Issue Type: New Feature
>  Components: Remote Service Admin
>Reporter: Johannes Utzig
>
> Fastbin should support InputStreams and OutputStreams as parameters and 
> return values of remote calls.
> Since streams cannot be serialized directly, the distribution provider should 
> replace the original objects with serializable proxies that load/write data 
> through additional remote requests.
> For sending large amounts of data this approach would work far better than 
> serializing a huge byte[]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIES-1587) Support streams in fastbin

2016-07-27 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1587:
-

 Summary: Support streams in fastbin
 Key: ARIES-1587
 URL: https://issues.apache.org/jira/browse/ARIES-1587
 Project: Aries
  Issue Type: New Feature
  Components: Remote Service Admin
Reporter: Johannes Utzig


Fastbin should support InputStreams and OutputStreams as parameters and return 
values of remote calls.
Since streams cannot be serialized directly, the distribution provider should 
replace the original objects with serializable proxies that load/write data 
through additional remote requests.
For sending large amounts of data this approach would work far better than 
serializing a huge byte[]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1586) Async calls in fastbin

2016-07-27 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1586:
---

Created a pull request
https://github.com/apache/aries-rsa/pull/13

> Async calls in fastbin
> --
>
> Key: ARIES-1586
> URL: https://issues.apache.org/jira/browse/ARIES-1586
> Project: Aries
>  Issue Type: New Feature
>  Components: Remote Service Admin
>Reporter: Johannes Utzig
>
> For long running remote calls it should be possible to make async remote 
> calls and receive e.g. a Future or osgi Promise as the result.
> Details have been discussed here:
> http://mail-archives.apache.org/mod_mbox/aries-dev/201607.mbox/%3CCAJLHLX_sh1oK1o2HurzvN8_kCKtegvmmf-pucJq3pTW92QqQQg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIES-1586) Async calls in fastbin

2016-07-27 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1586:
-

 Summary: Async calls in fastbin
 Key: ARIES-1586
 URL: https://issues.apache.org/jira/browse/ARIES-1586
 Project: Aries
  Issue Type: New Feature
  Components: Remote Service Admin
Reporter: Johannes Utzig


For long running remote calls it should be possible to make async remote calls 
and receive e.g. a Future or osgi Promise as the result.
Details have been discussed here:
http://mail-archives.apache.org/mod_mbox/aries-dev/201607.mbox/%3CCAJLHLX_sh1oK1o2HurzvN8_kCKtegvmmf-pucJq3pTW92QqQQg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1581) RSA does not include the ExportReference in RSA Events

2016-06-23 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1581:
---

Understood. The change in the pull request will still render the 
ExportReference 'useless' as required by the spec.

> RSA does not include the ExportReference in RSA Events
> --
>
> Key: ARIES-1581
> URL: https://issues.apache.org/jira/browse/ARIES-1581
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>
> When an exported service is removed, the RemoteServiceAdminEvent contains 
> 'null' as the ExportReference.
> I will create a pull request



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1581) RSA does not include the ExportReference in RSA Events

2016-06-23 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1581:
---

The problem is not so much that it is closed and no longer provides access to 
the EndpointDescription, but the ExportReference is actually null, because the 
ExportRegistration returns null when it is closed.

> RSA does not include the ExportReference in RSA Events
> --
>
> Key: ARIES-1581
> URL: https://issues.apache.org/jira/browse/ARIES-1581
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>
> When an exported service is removed, the RemoteServiceAdminEvent contains 
> 'null' as the ExportReference.
> I will create a pull request



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1582) fastbin should handle object methods locally

2016-06-23 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1582:
---

Created a pull request https://github.com/apache/aries-rsa/pull/10

> fastbin should handle object methods locally
> 
>
> Key: ARIES-1582
> URL: https://issues.apache.org/jira/browse/ARIES-1582
> Project: Aries
>  Issue Type: Improvement
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>
> The proxy created by the fastbin provider should handle object methods 
> (equals, hashcode, ...) as local calls instead of remote calls.
> There is hardly any scenario where people want to use those as actual remote 
> calls and remote hashcode/equals creates a severe performance penalty when 
> the remote objects are stored in a list or map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1581) RSA does not include the ExportReference in RSA Events

2016-06-23 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1581:
---

Pull request created https://github.com/apache/aries-rsa/pull/9

> RSA does not include the ExportReference in RSA Events
> --
>
> Key: ARIES-1581
> URL: https://issues.apache.org/jira/browse/ARIES-1581
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>
> When an exported service is removed, the RemoteServiceAdminEvent contains 
> 'null' as the ExportReference.
> I will create a pull request



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIES-1582) fastbin should handle object methods locally

2016-06-23 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1582:
-

 Summary: fastbin should handle object methods locally
 Key: ARIES-1582
 URL: https://issues.apache.org/jira/browse/ARIES-1582
 Project: Aries
  Issue Type: Improvement
  Components: Remote Service Admin
Affects Versions: rsa-1.8.0
Reporter: Johannes Utzig


The proxy created by the fastbin provider should handle object methods (equals, 
hashcode, ...) as local calls instead of remote calls.
There is hardly any scenario where people want to use those as actual remote 
calls and remote hashcode/equals creates a severe performance penalty when the 
remote objects are stored in a list or map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1577) Deadlock in TopologyManagerImport

2016-06-21 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1577:
---

Opened a pull request: https://github.com/apache/aries-rsa/pull/6

> Deadlock in TopologyManagerImport
> -
>
> Key: ARIES-1577
> URL: https://issues.apache.org/jira/browse/ARIES-1577
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>
> TopologyManagerImport caused a deadlock. See attached stack information (I'll 
> try to create a pull request)
> {code:java}Found one Java-level deadlock:
> =
> "pool-107-thread-2":
>   waiting to lock monitor 0x36016928 (object 0x0006c276e118, a 
> java.util.HashMap),
>   which is held by "pool-107-thread-1"
> "pool-107-thread-1":
>   waiting to lock monitor 0x342829d8 (object 0x0006cca8bb38, a 
> java.util.concurrent.ConcurrentHashMap),
>   which is held by "Thread-74"
> "Thread-74":
>   waiting to lock monitor 0x36016928 (object 0x0006c276e118, a 
> java.util.HashMap),
>   which is held by "pool-107-thread-1"
> Java stack information for the threads listed above:
> ===
> "pool-107-thread-2":
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.unexportNotAvailableServices(TopologyManagerImport.java:214)
> - waiting to lock <0x0006c276e118> (a java.util.HashMap)
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.access$0(TopologyManagerImport.java:212)
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport$1.run(TopologyManagerImport.java:202)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "pool-107-thread-1":
> at 
> org.jboss.osgi.framework.internal.FrameworkEventsPlugin.fireServiceEvent(FrameworkEventsPlugin.java:479)
> - waiting to lock <0x0006cca8bb38> (a 
> java.util.concurrent.ConcurrentHashMap)
> at 
> org.jboss.osgi.framework.internal.ServiceManagerPlugin.registerService(ServiceManagerPlugin.java:201)
> at 
> org.jboss.osgi.framework.internal.AbstractBundleContext.registerService(AbstractBundleContext.java:301)
> at 
> org.jboss.osgi.framework.internal.AbstractBundleContext.registerService(AbstractBundleContext.java:293)
> at 
> org.apache.aries.rsa.core.RemoteServiceAdminCore.exposeServiceFactory(RemoteServiceAdminCore.java:421)
> at 
> org.apache.aries.rsa.core.RemoteServiceAdminCore.importService(RemoteServiceAdminCore.java:375)
> - locked <0x0006c274bb50> (a java.util.LinkedHashMap)
> at 
> org.apache.aries.rsa.core.RemoteServiceAdminInstance$2.run(RemoteServiceAdminInstance.java:80)
> at 
> org.apache.aries.rsa.core.RemoteServiceAdminInstance$2.run(RemoteServiceAdminInstance.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.aries.rsa.core.RemoteServiceAdminInstance.importService(RemoteServiceAdminInstance.java:78)
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.importService(TopologyManagerImport.java:288)
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.importServices(TopologyManagerImport.java:252)
> - locked <0x0006c276e118> (a java.util.HashMap)
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.access$1(TopologyManagerImport.java:244)
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport$1.run(TopologyManagerImport.java:203)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "Thread-74":
> at 
> org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.removeServiceInterest(TopologyManagerImport.java:129)
> - waiting to lock <0x0006c276e118> (a java.util.HashMap)
> at 
> org.apache.aries.rsa.topologymanager.importer.ListenerHookImpl.removed(ListenerHookImpl.java:103)
> at 
> org.jboss.osgi.framework.internal.FrameworkEventsPlugin.removeServiceListener(FrameworkEventsPlugin.java:304)
> - locked <0x0006cca8bb38> (a java.util.concurrent.ConcurrentHashMap)
> at 
> org.jboss.osgi.framework.internal.AbstractBundleContext.removeServiceListener(AbstractBundleContext.java:262)
> at 
> org.apache.felix.scr.impl.manager.ServiceTracker.close(ServiceTracker.java:400)
> - locked <0x00072591b008> (a 
> 

[jira] [Created] (ARIES-1577) Deadlock in TopologyManagerImport

2016-06-21 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1577:
-

 Summary: Deadlock in TopologyManagerImport
 Key: ARIES-1577
 URL: https://issues.apache.org/jira/browse/ARIES-1577
 Project: Aries
  Issue Type: Bug
  Components: Remote Service Admin
Affects Versions: rsa-1.8.0
Reporter: Johannes Utzig


TopologyManagerImport caused a deadlock. See attached stack information (I'll 
try to create a pull request)

{code:java}Found one Java-level deadlock:
=
"pool-107-thread-2":
  waiting to lock monitor 0x36016928 (object 0x0006c276e118, a 
java.util.HashMap),
  which is held by "pool-107-thread-1"
"pool-107-thread-1":
  waiting to lock monitor 0x342829d8 (object 0x0006cca8bb38, a 
java.util.concurrent.ConcurrentHashMap),
  which is held by "Thread-74"
"Thread-74":
  waiting to lock monitor 0x36016928 (object 0x0006c276e118, a 
java.util.HashMap),
  which is held by "pool-107-thread-1"

Java stack information for the threads listed above:
===
"pool-107-thread-2":
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.unexportNotAvailableServices(TopologyManagerImport.java:214)
- waiting to lock <0x0006c276e118> (a java.util.HashMap)
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.access$0(TopologyManagerImport.java:212)
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport$1.run(TopologyManagerImport.java:202)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
"pool-107-thread-1":
at 
org.jboss.osgi.framework.internal.FrameworkEventsPlugin.fireServiceEvent(FrameworkEventsPlugin.java:479)
- waiting to lock <0x0006cca8bb38> (a 
java.util.concurrent.ConcurrentHashMap)
at 
org.jboss.osgi.framework.internal.ServiceManagerPlugin.registerService(ServiceManagerPlugin.java:201)
at 
org.jboss.osgi.framework.internal.AbstractBundleContext.registerService(AbstractBundleContext.java:301)
at 
org.jboss.osgi.framework.internal.AbstractBundleContext.registerService(AbstractBundleContext.java:293)
at 
org.apache.aries.rsa.core.RemoteServiceAdminCore.exposeServiceFactory(RemoteServiceAdminCore.java:421)
at 
org.apache.aries.rsa.core.RemoteServiceAdminCore.importService(RemoteServiceAdminCore.java:375)
- locked <0x0006c274bb50> (a java.util.LinkedHashMap)
at 
org.apache.aries.rsa.core.RemoteServiceAdminInstance$2.run(RemoteServiceAdminInstance.java:80)
at 
org.apache.aries.rsa.core.RemoteServiceAdminInstance$2.run(RemoteServiceAdminInstance.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.aries.rsa.core.RemoteServiceAdminInstance.importService(RemoteServiceAdminInstance.java:78)
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.importService(TopologyManagerImport.java:288)
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.importServices(TopologyManagerImport.java:252)
- locked <0x0006c276e118> (a java.util.HashMap)
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.access$1(TopologyManagerImport.java:244)
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport$1.run(TopologyManagerImport.java:203)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
"Thread-74":
at 
org.apache.aries.rsa.topologymanager.importer.TopologyManagerImport.removeServiceInterest(TopologyManagerImport.java:129)
- waiting to lock <0x0006c276e118> (a java.util.HashMap)
at 
org.apache.aries.rsa.topologymanager.importer.ListenerHookImpl.removed(ListenerHookImpl.java:103)
at 
org.jboss.osgi.framework.internal.FrameworkEventsPlugin.removeServiceListener(FrameworkEventsPlugin.java:304)
- locked <0x0006cca8bb38> (a java.util.concurrent.ConcurrentHashMap)
at 
org.jboss.osgi.framework.internal.AbstractBundleContext.removeServiceListener(AbstractBundleContext.java:262)
at 
org.apache.felix.scr.impl.manager.ServiceTracker.close(ServiceTracker.java:400)
- locked <0x00072591b008> (a 
org.apache.felix.scr.impl.manager.ServiceTracker)
at 
org.apache.felix.scr.impl.manager.DependencyManager.unregisterServiceListener(DependencyManager.java:1972)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.disableDependencyManagers(AbstractComponentManager.java:1352)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:912)
at 

[jira] [Commented] (ARIES-1556) fastbin provider fails if local host cannot be resolved

2016-05-31 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1556:
---

Added a pull request
https://github.com/apache/aries-rsa/pull/3

> fastbin provider fails if local host cannot be resolved
> ---
>
> Key: ARIES-1556
> URL: https://issues.apache.org/jira/browse/ARIES-1556
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>
> TcpTransport tries to check if the remote host is actually the localhost and 
> uses localhost in such a case.
> However, if 'InetAddress.getLocalHost().getHostName()' throws an 
> UnknownHostException, the TcpTransport is not created and all invocations 
> starve in the queue until the timeout is reached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIES-1556) fastbin provider fails if local host cannot be resolved

2016-05-31 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1556:
-

 Summary: fastbin provider fails if local host cannot be resolved
 Key: ARIES-1556
 URL: https://issues.apache.org/jira/browse/ARIES-1556
 Project: Aries
  Issue Type: Bug
  Components: Remote Service Admin
Affects Versions: rsa-1.8.0
Reporter: Johannes Utzig


TcpTransport tries to check if the remote host is actually the localhost and 
uses localhost in such a case.
However, if 'InetAddress.getLocalHost().getHostName()' throws an 
UnknownHostException, the TcpTransport is not created and all invocations 
starve in the queue until the timeout is reached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1518) RSA exports services that don't match the DistributionProvider

2016-04-06 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1518:
---

created a Pull request https://github.com/apache/aries-rsa/pull/1

> RSA exports services that don't match the DistributionProvider
> --
>
> Key: ARIES-1518
> URL: https://issues.apache.org/jira/browse/ARIES-1518
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>Assignee: Christian Schneider
> Fix For: rsa-2.0.0
>
>
> When trying to export a service the RSA ignores the supported types of the 
> DistributionProvider and exports the service regardless of the 
> 'service.exported.configs' property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (ARIES-1519) NPE when DistributionProvider has no remote.intents.supported

2016-04-06 Thread Johannes Utzig (JIRA)

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

Johannes Utzig commented on ARIES-1519:
---

Created a Pull request https://github.com/apache/aries-rsa/pull/2

> NPE when DistributionProvider has no remote.intents.supported
> -
>
> Key: ARIES-1519
> URL: https://issues.apache.org/jira/browse/ARIES-1519
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.8.0
>Reporter: Johannes Utzig
>Assignee: Christian Schneider
>Priority: Minor
> Fix For: rsa-2.0.0
>
>
> When a DistributionProvider has no 'remote.intents.supported' set, the 
> DistributionProviderTracker throws an NPE when trying to create the RSA 
> instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIES-1519) NPE when DistributionProvider has no remote.intents.supported

2016-04-06 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1519:
-

 Summary: NPE when DistributionProvider has no 
remote.intents.supported
 Key: ARIES-1519
 URL: https://issues.apache.org/jira/browse/ARIES-1519
 Project: Aries
  Issue Type: Bug
  Components: Remote Service Admin
Affects Versions: rsa-1.8.0
Reporter: Johannes Utzig
Priority: Minor


When a DistributionProvider has no 'remote.intents.supported' set, the 
DistributionProviderTracker throws an NPE when trying to create the RSA instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIES-1518) RSA exports services that don't match the DistributionProvider

2016-04-06 Thread Johannes Utzig (JIRA)
Johannes Utzig created ARIES-1518:
-

 Summary: RSA exports services that don't match the 
DistributionProvider
 Key: ARIES-1518
 URL: https://issues.apache.org/jira/browse/ARIES-1518
 Project: Aries
  Issue Type: Bug
  Components: Remote Service Admin
Affects Versions: rsa-1.8.0
Reporter: Johannes Utzig


When trying to export a service the RSA ignores the supported types of the 
DistributionProvider and exports the service regardless of the 
'service.exported.configs' property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)