[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1616:


Commit 1761786 from [~timothyjward] in branch 'aries/trunk'
[ https://svn.apache.org/r1761786 ]

ARIES-1616 Clean up Local JPA resources properly

> Transaction Recovery Log does not shut down properly
> 
>
> Key: ARIES-1616
> URL: https://issues.apache.org/jira/browse/ARIES-1616
> Project: Aries
>  Issue Type: Bug
>  Components: tx-control
>Affects Versions: tx-control-0.0.1
>Reporter: Timothy Ward
>Assignee: Timothy Ward
> Fix For: tx-control-0.0.2
>
>
> After shutting down or reconfiguring the XA Transaction Control 
> implementation a daemon thread is left running from the HOWL Flush manager. 
> This never seems to get closed...
> This is likely a bug in HOWL, but that project hasn't been updated in a 
> decade so Aries will have to work around it.



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

[jira] [Updated] (ARIES-1618) Regression after ARIES-1342: Duplicate interface name in class file

[Vladimir Konkov (JIRA)]

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

Vladimir Konkov updated ARIES-1618:
---
Priority: Critical  (was: Major)

Raise the priority because this bug breaks service import of interfaces with 
duplicated in inheritance. 

> Regression after ARIES-1342: Duplicate interface name in class file
> ---
>
> Key: ARIES-1618
> URL: https://issues.apache.org/jira/browse/ARIES-1618
> Project: Aries
>  Issue Type: Bug
>  Components: Proxy
>Affects Versions: proxy-impl-1.0.5
> Environment: Karaf 4.0.6, JDK 1.8.0_u77
>Reporter: Vladimir Konkov
>Priority: Critical
>
> I have regression on Karaf 4.0.6 (Proxy Service 1.0.5) with such blueprint 
> config:
> {code:xml}
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0;>
> interface="org.apache.aries.transaction.AriesTransactionManager"/>
> 
> 
> {code}
> Because of hierarchy ordering fix in ARIES-1342 resulting interfaces set 
> contains duplicates (!) - two javax.transaction.TransactionManager entries. 
> As result Exception thrown on proxy class generation:
> {noformat}
> Caused by: org.apache.aries.proxy.UnableToProxyException: 
> java.lang.ClassFormatError: Duplicate interface name in class file 
> Proxy3636dfb0_3a9f_46d5_8eb4_32506b8a33ae
>   at 
> org.apache.aries.proxy.impl.interfaces.ProxyClassLoader.createProxyClass(ProxyClassLoader.java:165)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.interfaces.InterfaceProxyGenerator.getProxyInstance(InterfaceProxyGenerator.java:97)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.AsmProxyManager.createNewProxy(AsmProxyManager.java:80)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingInterceptingProxy(AbstractProxyManager.java:75)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingProxy(AbstractProxyManager.java:40)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.createProxy(AbstractServiceReferenceRecipe.java:332)[12:org.apache.aries.blueprint.core:1.6.2]
>   at 
> org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:107)[12:org.apache.aries.blueprint.core:1.6.2]
> {noformat}



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

[jira] [Commented] (ARIES-1618) Regression after ARIES-1342: Duplicate interface name in class file

[Vladimir Konkov (JIRA)]

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

Vladimir Konkov commented on ARIES-1618:


It seems that comparator do not do transitive comparison on which sort 
algorithm in TreeSet is relaying. Resulting interfaces for 
org.apache.aries.transaction.AriesTransactionManager :

{noformat}
0 = {Class@723} "interface javax.transaction.TransactionManager"
1 = {Class@722} "interface javax.transaction.UserTransaction"
2 = {Class@721} "interface javax.transaction.TransactionSynchronizationRegistry"
3 = {Class@770} "interface org.apache.geronimo.transaction.manager.XidImporter"
4 = {Class@4910} "interface java.util.EventListener"
5 = {Class@769} "interface 
org.apache.geronimo.transaction.manager.MonitorableTransactionManager"
6 = {Class@723} "interface javax.transaction.TransactionManager"
7 = {Class@768} "interface 
org.apache.geronimo.transaction.manager.RecoverableTransactionManager"
8 = {Class@720} "interface javax.resource.spi.XATerminator"
9 = {Class@767} "interface org.apache.geronimo.transaction.manager.XAWork"
10 = {Class@766} "interface 
org.apache.aries.transaction.AriesTransactionManager"
{noformat}

TransactionManager interface is direct parent of RecoverableTransactionManager 
and AriesTransactionManager itself.

> Regression after ARIES-1342: Duplicate interface name in class file
> ---
>
> Key: ARIES-1618
> URL: https://issues.apache.org/jira/browse/ARIES-1618
> Project: Aries
>  Issue Type: Bug
>  Components: Proxy
>Affects Versions: proxy-impl-1.0.5
> Environment: Karaf 4.0.6, JDK 1.8.0_u77
>Reporter: Vladimir Konkov
>
> I have regression on Karaf 4.0.6 (Proxy Service 1.0.5) with such blueprint 
> config:
> {code:xml}
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0;>
> interface="org.apache.aries.transaction.AriesTransactionManager"/>
> 
> 
> {code}
> Because of hierarchy ordering fix in ARIES-1342 resulting interfaces set 
> contains duplicates (!) - two javax.transaction.TransactionManager entries. 
> As result Exception thrown on proxy class generation:
> {noformat}
> Caused by: org.apache.aries.proxy.UnableToProxyException: 
> java.lang.ClassFormatError: Duplicate interface name in class file 
> Proxy3636dfb0_3a9f_46d5_8eb4_32506b8a33ae
>   at 
> org.apache.aries.proxy.impl.interfaces.ProxyClassLoader.createProxyClass(ProxyClassLoader.java:165)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.interfaces.InterfaceProxyGenerator.getProxyInstance(InterfaceProxyGenerator.java:97)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.AsmProxyManager.createNewProxy(AsmProxyManager.java:80)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingInterceptingProxy(AbstractProxyManager.java:75)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingProxy(AbstractProxyManager.java:40)[20:org.apache.aries.proxy.impl:1.0.5]
>   at 
> org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.createProxy(AbstractServiceReferenceRecipe.java:332)[12:org.apache.aries.blueprint.core:1.6.2]
>   at 
> org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:107)[12:org.apache.aries.blueprint.core:1.6.2]
> {noformat}



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1613:
-

The topology manager has the ability to override service properties, see 
https://osgi.org/javadoc/r6/enterprise/org/osgi/service/remoteserviceadmin/RemoteServiceAdmin.html#exportService(org.osgi.framework.ServiceReference,%20java.util.Map)

You are correct that the Topology Manager cannot override properties created by 
the Distribution provider (which don't exist) but that is correct. The 
Distribution provider understands its own properties better than the Topology 
Manager ever can. In the case where a different URL is available it needs to be 
the Distribution Provider which indicates that by providing an extra 
ExportRegistration in the returned list.

> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1613:
-

> From a security standpoint I think the only good solution for your case is to 
> have two separate zookeeper instances and a bridge between them that does the 
> filtering and proxy setup. With one zookeeper it would be very difficult to 
> hide some of the information.

I honestly believe that this is overkill - firewalls and filters which check 
origin IP addresses can protect the raw endpoint, which should really be on a 
private network anyway. The Endpoint information in zookeeper should be 
"private" to the discovery layer and used correctly by the client Topology 
Manager.

> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[Christian Schneider (JIRA)]

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

Christian Schneider commented on ARIES-1613:


I agree that that TopologyManager is the better place to do the propety 
changes. One problem I see is that in the spec the TopologyManager is only 
allowed to add extra properties. It is not allowed to override some. Is there a 
special reason for this limitation. I think it would be good to let the 
TopologyManager theoretically do any changes on the properties - of course 
while keeping in mind that not all changes will result in a working system. 

> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1613:
-

> If I understood correctly, "remote Topology Manager" is the one running on 
> the remote client, right?

There are two topology managers installed, one on the "server" side and one on 
the "client" side. 

The "server" topology manager is the one who can add extra properties when 
exporting the service, and who gets to decide the following things:

1. Which distribution providers should be used for export
2. What extra properties should be exported alongside the service properties
3. Which endpoint descriptions should be sent to the local Endpoint Event 
Listeners in the framework
4. What to do on endpoint faliure

The "client" topology manager receives endpoint notifications from discovery, 
which should be passing the Endpoints unadulterated and can:

1. Decide to import, ignore or save an endpoint description for later
2. Decide which distribution provider(s) to try importing the service with
3. What to do on endpoint failure


> it would be nice (at least from security, or hardening, perspective) that 
> they did not know anything about (i.e. they do not see) the "raw" 
> EndpointDescription.

The correct place to do the security check here is in a firewall and/or filter 
on the "raw" servlet, to check access is not from outside, otherwise someone 
could simply guess the URL. Also, by choosing to ignore the raw URL it remains 
invisible as a service (i.e. no imported OSGi service exists).

If you really want to partition your discovery space then what you need are two 
discovery providers (or two configurations of the same discovery provider) 
which have different discovery domains. Again, these would not change the 
endpoint properties, but the server topology can determine which 
EndpointEventListener is called for which EndpointDescription.


> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[Christian Schneider (JIRA)]

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

Christian Schneider commented on ARIES-1613:


>From a security standpoint I think the only good solution for your case is to 
>have two separate zookeeper instances and a bridge between them that does the 
>filtering and proxy setup. With one zookeeper it would be very difficult to 
>hide some of the information.

> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[JIRA]

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

Panu Hämäläinen commented on ARIES-1613:


Just a note, not arguing on where the "address change support" should be 
implemented: 

If I understood correctly, "remote Topology Manager" is the one running on the 
remote client, right? For the remote clients (and thus Topology Managers 
running on them) that connect via the proxy, it would be nice (at least from 
security, or hardening, perspective) that they did not know anything about 
(i.e. they do not see) the "raw" EndpointDescription.

> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

[jira] [Commented] (ARIES-1613) DiscoveryPlugin interface not exported

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1613:
-

Discovery providers should not be changing the properties defined by an 
EndpointDescription. The Topology Manager is responsible for adding extra 
properties when making the export from RemoteServiceAdmin. Changing the 
properties in the Discovery layer is a good way to break other RSA 
implementations.

The sort of behaviour that you're actually asking for (the ability to supply an 
"external" URL) should really be part of the RSA distribution provider. The 
provider should create a proxied EndpointDescription and a "raw" 
EndpointDescription, the remote Topology Manager can then decide which (or 
both) should be imported.

> DiscoveryPlugin interface not exported
> --
>
> Key: ARIES-1613
> URL: https://issues.apache.org/jira/browse/ARIES-1613
> Project: Aries
>  Issue Type: Bug
>  Components: Remote Service Admin
>Affects Versions: rsa-1.9.0
>Reporter: Panu Hämäläinen
>
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.



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

Re: [Discuss] Support zones for Aries RSA. Also related to cloud support

[Timothy Ward]

Hi Christian,

From an RSA perspective this is a Topology Management issue, not a discovery 
issue. Services should be exposed by the Distribution Provider with multiple 
ExportRegistrations (and hence multiple EndpointDescriptions), one for the 
“internal” URL and one for the “proxied” URL The Topology Manager on the client 
side should then import the Endpoint Description that gives the behaviour that 
it desires.

Using multiple discovery services to do this sort of scoping is possible, but 
much more complicated than controlling it using the Topology Manager. Adding a 
simple filter to the client side’s Topology Manager’s EndpointEventListener 
would probably be sufficient, and could be done easily using Config Admin.

Regards,

Tim


> On 19 Sep 2016, at 13:52, Christian Schneider  wrote:
> 
> I just had a discussion with Panu Hämäläinen about the DiscoveryPlugin 
> mechanism.
> See https://issues.apache.org/jira/browse/ARIES-1613 and 
> https://issues.apache.org/jira/browse/ARIES-1614 .
> 
> What he needs is to have two zones of services, a backend zone and a frontend 
> zone.
> 
> The (or some) services in the backend will be published with http. Inside the 
> backend zone the services should be available using this http url.
> 
> In the frontend zone these services should also be visible but their url 
> should point to a proxy server that offer a https connection and potentially 
> some additional security mechanisms.
> 
> So we can not simply have one (zookeeper or other) discovery view. Instead we 
> need a different discovery view for backend and frontend and some mechanism 
> to make some services from one zone available in the other while also 
> applying some changes like pointing to a proxy.
> 
> Do you think it makes sense to support this case in Aries RSA in some way?
> 
> I thought we might also be able to interact with one of the existing proxy 
> servers to automatically register the proxy for each service. Such a 
> mechanism is very typically for cloud enabled architectures. So that might 
> also bring us nearer to good cloud support.
> 
> I would be happy about any ideas and feedback.
> 
> Christian
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

[jira] [Commented] (ARIES-1612) Zip input stream relies on default (non buffered) InputStream read

[Tom De Wolf (JIRA)]

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

Tom De Wolf commented on ARIES-1612:


[~jwr...@us.ibm.com] are you also able to create a new aries util release? or 
point us to the person who can?

> Zip input stream relies on default (non buffered) InputStream read
> --
>
> Key: ARIES-1612
> URL: https://issues.apache.org/jira/browse/ARIES-1612
> Project: Aries
>  Issue Type: Bug
>  Components: Util
>Affects Versions: util-1.1.1
>Reporter: Paul Thevenot
>Assignee: Thomas Watson
> Fix For: util-1.1.2
>
>
> We have performances issues on application startup. It takes a while to 
> install all the bundles of a subsystem. After a quick look with JProfiler, we 
> saw that the SpecialZipInputStream.read() was invoked 44 millions times 
> during startup. 
> We're using the Felix framework and the BundleCache.copyStreamToFile calls 
> the method read(byte[] b) from the InputStream. Unfortunately, the method 
> read(byte[] b) and read(byte[] b, int off, int len) are not overriden by the 
> SpecialZipInputStream (thus we don't buffer the read). 
> Completing the decoration in the SpecialZipInputStream solved this problem 
> and divided the startup time by two.
> I've made the pull request with the requested change 
> https://github.com/apache/aries/pull/55



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

[jira] [Resolved] (ARIES-1616) Transaction Recovery Log does not shut down properly

[Timothy Ward (JIRA)]

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

Timothy Ward resolved ARIES-1616.
-
Resolution: Fixed

Fixed with tests in r1761694

> Transaction Recovery Log does not shut down properly
> 
>
> Key: ARIES-1616
> URL: https://issues.apache.org/jira/browse/ARIES-1616
> Project: Aries
>  Issue Type: Bug
>  Components: tx-control
>Affects Versions: tx-control-0.0.1
>Reporter: Timothy Ward
>Assignee: Timothy Ward
> Fix For: tx-control-0.0.2
>
>
> After shutting down or reconfiguring the XA Transaction Control 
> implementation a daemon thread is left running from the HOWL Flush manager. 
> This never seems to get closed...
> This is likely a bug in HOWL, but that project hasn't been updated in a 
> decade so Aries will have to work around it.



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

[jira] [Commented] (ARIES-1616) Transaction Recovery Log does not shut down properly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1616:


Commit 1761694 from [~timothyjward] in branch 'aries/trunk'
[ https://svn.apache.org/r1761694 ]

ARIES-1616 Force the transaction log to close when Transaction Control shuts 
down

> Transaction Recovery Log does not shut down properly
> 
>
> Key: ARIES-1616
> URL: https://issues.apache.org/jira/browse/ARIES-1616
> Project: Aries
>  Issue Type: Bug
>  Components: tx-control
>Affects Versions: tx-control-0.0.1
>Reporter: Timothy Ward
>Assignee: Timothy Ward
> Fix For: tx-control-0.0.2
>
>
> After shutting down or reconfiguring the XA Transaction Control 
> implementation a daemon thread is left running from the HOWL Flush manager. 
> This never seems to get closed...
> This is likely a bug in HOWL, but that project hasn't been updated in a 
> decade so Aries will have to work around it.



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

[jira] [Created] (ARIES-1616) Transaction Recovery Log does not shut down properly

[Timothy Ward (JIRA)]

Timothy Ward created ARIES-1616:
---

 Summary: Transaction Recovery Log does not shut down properly
 Key: ARIES-1616
 URL: https://issues.apache.org/jira/browse/ARIES-1616
 Project: Aries
  Issue Type: Bug
  Components: tx-control
Affects Versions: tx-control-0.0.1
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: tx-control-0.0.2


After shutting down or reconfiguring the XA Transaction Control implementation 
a daemon thread is left running from the HOWL Flush manager. This never seems 
to get closed...

This is likely a bug in HOWL, but that project hasn't been updated in a decade 
so Aries will have to work around it.



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