[jira] [Updated] (TUSCANY-3770) Tomcat 7 reports a memory leak when stopping a Tuscany webapp
[ https://issues.apache.org/jira/browse/TUSCANY-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-3770: Attachment: ThreadMessageContext.java.patch A patch for the 2.x code base. Want to do this fix separately so I can be sure I'm not messing anything up. Tomcat 7 reports a memory leak when stopping a Tuscany webapp - Key: TUSCANY-3770 URL: https://issues.apache.org/jira/browse/TUSCANY-3770 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Affects Versions: Java-SCA-1.6 Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-1.6.1 Attachments: ThreadMessageContext.java.patch On Tomcat 7, when a Tuscany webapp is stopped, the following message is displayed: SEVERE: The web application [/sample-calculator-webapp] created a ThreadLocal with key of type [null] (value [org.apache.tuscany.sca.core.invocation.ThreadMessageContext$1@1b071c0]) and a value of type [org.apache.tuscany.sca.core.invocation.MessageImpl] (value [org.apache.tuscany.sca.core.invocation.MessageImpl@fbf51d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. This happens because Tuscany adds a thread-local ThreadMessageContext object to every invocation thread when starting a request invocation and doesn't remove this object when the request is complete. There is code in WebAppServletHost.destroy() that attempts to remove this context information when the webapp is stopped. This usually doesn't succeed in removing the context information because the ThreadLocal.remove() method only removes context information from the current thread and not from other threads. There's no Java API for removing this information from other threads. The only way to remove this information is to track the completion of each request invocation and remove the context information from the current thread when the request has been completed. The context information will be recreated for the next request on the thread. This is very easy to implement by adding a few lines of code to the ThreadMessageContext class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite
[
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws updated TUSCANY-3459:
Attachment: 3459.patch
General changes to make the infrastructure apply the remotable overide.
JSON-RPC (and other) binding fails if Interface is marked as remotable only
in the composite
-
Key: TUSCANY-3459
URL: https://issues.apache.org/jira/browse/TUSCANY-3459
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.x
Attachments: 3459.patch
public interface Catalog {
Item[] get();
}
component name=VegetablesCatalog
implementation.java class=services.sca.FruitsCatalogImpl/
service name=Catalog
interface.java interface=services.Catalog
remotable=true/
tuscany:binding.jsonrpc
uri=http://localhost:8085/VegetableCatalog; /
/service
/component
at $Proxy7.get(Unknown Source)
at services.sca.CatalogAggregatorImpl.get(CatalogAggregatorImpl.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:115)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
at $Proxy7.get(Unknown Source)
at
org.apache.tuscany.sca.performance.CatalogRemoteJsonRPCTest.testCatalog(CatalogRemoteJsonRPCTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestDecorator.run(TestDecorator.java:32)
at junit.extensions.RepeatedTest.run(RepeatedTest.java:30)
at com.clarkware.junitperf.ThreadedTest$TestRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jabsorb.serializer.UnmarshallException: element 0 no
serializer found that can unmarshall java.lang.String to services.Item
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:216)
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:692)
at org.jabsorb.client.Client.invoke(Client.java:226)
at org.jabsorb.client.Client.invoke(Client.java:156)
at
org.apache.tuscany.sca.binding.jsonrpc.provider.JSONRPCClientInvoker.invoke(JSONRPCClientInvoker.java:60)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
... 27 more
Caused by: org.jabsorb.serializer.UnmarshallException: no serializer found
that can unmarshall java.lang.String to services.Item
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:705)
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:209)
... 33 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-4007) Mutliple delegations for binding.sca
[ https://issues.apache.org/jira/browse/TUSCANY-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-4007: Attachment: delegation-v2.patch Updates to the original patch. Putting here for backup. Am going off this approach a little as it's got a bit more complicated. Mutliple delegations for binding.sca Key: TUSCANY-4007 URL: https://issues.apache.org/jira/browse/TUSCANY-4007 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Attachments: delegation-v2.patch, delegation.patch I've come across a situation where I'd like to support multiple remote delegations for a single binding.sca instance. This came up because I was looking at a situation where I wanted to support reliable and non-reliable comms at the same time so thought I would experiment with delegating to different underlying binding implementations. Currently the code doesn't allow you to do that as it assumes a local delegation and a single remote delegation are represented by the single binding.sca instance take from the component model. I've attached a patch with a fix to make this work. It creates a new endpoint for each required delegation. Am going to raise on the dev list before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-4007) Mutliple delegations for binding.sca
[ https://issues.apache.org/jira/browse/TUSCANY-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-4007: Attachment: delegation.patch Mutliple delegations for binding.sca Key: TUSCANY-4007 URL: https://issues.apache.org/jira/browse/TUSCANY-4007 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Attachments: delegation.patch I've come across a situation where I'd like to support multiple remote delegations for a single binding.sca instance. This came up because I was looking at a situation where I wanted to support reliable and non-reliable comms at the same time so thought I would experiment with delegating to different underlying binding implementations. Currently the code doesn't allow you to do that as it assumes a local delegation and a single remote delegation are represented by the single binding.sca instance take from the component model. I've attached a patch with a fix to make this work. It creates a new endpoint for each required delegation. Am going to raise on the dev list before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3882) Are there any changes in 1.x that we still need to apply to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-3882: Attachment: edited-list-2.txt Here's a list based on the revisions made to 1.x after the 2.x branch was taken. I've taken a pass through this list (hence the -2 suffix) and removed what seem to have been applied to 2.x already. It may be that the majority of the changes in this list are not required for 2.x we just need to go through an check. Are there any changes in 1.x that we still need to apply to 2.x --- Key: TUSCANY-3882 URL: https://issues.apache.org/jira/browse/TUSCANY-3882 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-M5 Reporter: Simon Laws Fix For: Java-SCA-2.0 Attachments: edited-list-2.txt I don't know this to be true but I'm wondering if there are still changes in 1.x that we need in 2.x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
