You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by sc...@rogers.com on 2007/08/03 00:24:32 UTC
0.91 Memory Footprint
We recently migrated our version of Tuscany from M2 to 0.91, and we noticed that the memory consumption seems to have increased by quite a bit. When doing memory profiling, the culprit appeared to be classes related to Xerces DOM (DeferredElementNSImpl, several other schema element related classes). When profiling the samples (helloworld-ws-sdo-webapp) and our application in M2, those classes don't seem to get called. We are going through the jars to determine which module is triggering the Xerces parser, but any suggestions would be greatly appreciated.
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> Your latest proposal sounds good.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Sunday, August 05, 2007 7:20 PM
> Subject: Re: Dynamic registration of databindings, was: 0.91 Memory
> Footprint
>
>
>> Jean-Sebastien Delfino wrote:
>>> Raymond Feng wrote:
>>>> Hi,
>>>>
>>>> Your proposal looks good. I think it is consistent with the pattern
>>>> that we use to deal with unresolved models. IMO, the proxy/delegate
>>>> objects for databindings could be:
>>>>
>>>> DataBindingDelegate:
>>>> className = "my.MyDataBinding" (or ClassReference?)
>>>> DataBinding databinding; // transient instance lazily
>>>> instantiated from the class name
>>>> id = "db1"
>>>>
>>>> TransformerDelegate:
>>>> className = "my.DB12DB2Transformer"
>>>> Transformer instance; // transient instance lazily instantiated
>>>> from the class name
>>>> source = "DB1"
>>>> target = "DB2"
>>>> weight = 100
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>>> <js...@apache.org>
>>>> To: <tu...@ws.apache.org>
>>>> Sent: Sunday, August 05, 2007 10:57 AM
>>>> Subject: Dynamic registration of databindings, was: 0.91 Memory
>>>> Footprint
>>>>
>>>>
>>>>> Jean-Sebastien Delfino wrote:
>>>>>> scyip12@rogers.com wrote:
>>>>>>> We recently migrated our version of Tuscany from M2 to 0.91, and
>>>>>>> we noticed that the memory consumption seems to have increased
>>>>>>> by quite a bit. When doing memory profiling, the culprit
>>>>>>> appeared to be classes related to Xerces DOM
>>>>>>> (DeferredElementNSImpl, several other schema element related
>>>>>>> classes). When profiling the samples (helloworld-ws-sdo-webapp)
>>>>>>> and our application in M2, those classes don't seem to get
>>>>>>> called. We are going through the jars to determine which module
>>>>>>> is triggering the Xerces parser, but any suggestions would be
>>>>>>> greatly appreciated.
>>>>>>>
>>>>>>
>>>>>> I'm not sure which Tuscany extension triggers the loading of
>>>>>> Xerces yet, but the SDO-Axiom and JSON databindings and the EJB
>>>>>> and Script bindings seem to pull Xerces in their pom.xml.
>>>>>>
>>>>>> I noticed that in 0.91 most Tuscany extensions on the classpath
>>>>>> (and most of them are going to be on the classpath if you're
>>>>>> using tuscany-sca-all.jar) are aggressively loaded and
>>>>>> initialized when the runtime starts. I'm going to make some
>>>>>> changes to a number of binding and implementation extensions to
>>>>>> allow them to be loaded only when they are actually required by
>>>>>> an SCA assembly.
>>>>>>
>>>>>> I hope this will help.
>>>>>>
>>>>>
>>>>> I looked into most of the bindings and implementations, they are
>>>>> now loaded dynamically, this should help with the footprint. I
>>>>> think we need to do the same with data bindings as they are
>>>>> dragging a lot of dependencies and in most cases people will stick
>>>>> to a single databinding in their environment.
>>>>>
>>>>> Registering databindings should be easy:
>>>>>
>>>>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>>>>> <databinding class name>,id=<databinding id>
>>>>> <databinding class name>,id=<databinding id>
>>>>> etc.
>>>>>
>>>>> I'm not sure about transformers, but was thinking about something
>>>>> like this:
>>>>>
>>>>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>>>>> <transformer class name>,source=<databinding
>>>>> id>,target=<databinding id>,weight=<weight>
>>>>> <transformer class name>,source=<databinding
>>>>> id>,target=<databinding id>,weight=<weight>
>>>>> etc.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --
>>>>> Jean-Sebastien
>>>>>
>>>>>
>>>
>>> Most of the data binding initialization code seems to assume that
>>> data bindings extend BaseDataBinding by calling
>>> BaseDataBinding.setRegistry(...).
>>>
>>> I'm trying to understand why data bindings need to keep a pointer to
>>> the registry (actually the DataBindingExtensionPoint) and the only
>>> occurrence where it's used is in XMLStringDataBinding in:
>>>
>>> @Override
>>> public boolean introspect(DataType type, Annotation[] annotations) {
>>> if (registry.getDataBinding(type.getDataBinding()) == this) {
>>> type.setDataBinding(getName());
>>> type.setLogical(XMLType.UNKNOWN);
>>> return true;
>>> } else {
>>> return false;
>>> }
>>> }
>>>
>>> I don't understand what this code is for :) What does it do?
>>>
>>> Would the following alternative work?
>>>
>>> @Override
>>> public boolean introspect(DataType type, Annotation[] annotations) {
>>> if (getName().equals(type.getDataBinding())) {
>>> type.setLogical(XMLType.UNKNOWN);
>>> return true;
>>> } else {
>>> return false;
>>> }
>>> }
>>>
>>> Thanks
>>>
>>
>> or better (as it looks like data bindings can be identified by name
>> or by alias)?
>>
>> @Override
>> public boolean introspect(DataType type, Annotation[] annotations) {
>> String dataBinding = type.getDataBinding();
>> if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
>> type.setLogical(XMLType.UNKNOWN);
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>> --
>> Jean-Sebastien
>>
>>
>>
I just commited some changes to load the databindings dynamically. This
should help with the footprint.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Your latest proposal sounds good.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Sunday, August 05, 2007 7:20 PM
Subject: Re: Dynamic registration of databindings, was: 0.91 Memory
Footprint
> Jean-Sebastien Delfino wrote:
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> Your proposal looks good. I think it is consistent with the pattern that
>>> we use to deal with unresolved models. IMO, the proxy/delegate objects
>>> for databindings could be:
>>>
>>> DataBindingDelegate:
>>> className = "my.MyDataBinding" (or ClassReference?)
>>> DataBinding databinding; // transient instance lazily instantiated
>>> from the class name
>>> id = "db1"
>>>
>>> TransformerDelegate:
>>> className = "my.DB12DB2Transformer"
>>> Transformer instance; // transient instance lazily instantiated from
>>> the class name
>>> source = "DB1"
>>> target = "DB2"
>>> weight = 100
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>>> <js...@apache.org>
>>> To: <tu...@ws.apache.org>
>>> Sent: Sunday, August 05, 2007 10:57 AM
>>> Subject: Dynamic registration of databindings, was: 0.91 Memory
>>> Footprint
>>>
>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>> scyip12@rogers.com wrote:
>>>>>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>>>>>> noticed that the memory consumption seems to have increased by quite
>>>>>> a bit. When doing memory profiling, the culprit appeared to be
>>>>>> classes related to Xerces DOM (DeferredElementNSImpl, several other
>>>>>> schema element related classes). When profiling the samples
>>>>>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>>>>>> don't seem to get called. We are going through the jars to determine
>>>>>> which module is triggering the Xerces parser, but any suggestions
>>>>>> would be greatly appreciated.
>>>>>>
>>>>>
>>>>> I'm not sure which Tuscany extension triggers the loading of Xerces
>>>>> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
>>>>> bindings seem to pull Xerces in their pom.xml.
>>>>>
>>>>> I noticed that in 0.91 most Tuscany extensions on the classpath (and
>>>>> most of them are going to be on the classpath if you're using
>>>>> tuscany-sca-all.jar) are aggressively loaded and initialized when the
>>>>> runtime starts. I'm going to make some changes to a number of binding
>>>>> and implementation extensions to allow them to be loaded only when
>>>>> they are actually required by an SCA assembly.
>>>>>
>>>>> I hope this will help.
>>>>>
>>>>
>>>> I looked into most of the bindings and implementations, they are now
>>>> loaded dynamically, this should help with the footprint. I think we
>>>> need to do the same with data bindings as they are dragging a lot of
>>>> dependencies and in most cases people will stick to a single
>>>> databinding in their environment.
>>>>
>>>> Registering databindings should be easy:
>>>>
>>>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>>>> <databinding class name>,id=<databinding id>
>>>> <databinding class name>,id=<databinding id>
>>>> etc.
>>>>
>>>> I'm not sure about transformers, but was thinking about something like
>>>> this:
>>>>
>>>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>>>> <transformer class name>,source=<databinding id>,target=<databinding
>>>> id>,weight=<weight>
>>>> <transformer class name>,source=<databinding id>,target=<databinding
>>>> id>,weight=<weight>
>>>> etc.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Jean-Sebastien
>>>>
>>>>
>>
>> Most of the data binding initialization code seems to assume that data
>> bindings extend BaseDataBinding by calling
>> BaseDataBinding.setRegistry(...).
>>
>> I'm trying to understand why data bindings need to keep a pointer to the
>> registry (actually the DataBindingExtensionPoint) and the only occurrence
>> where it's used is in XMLStringDataBinding in:
>>
>> @Override
>> public boolean introspect(DataType type, Annotation[] annotations) {
>> if (registry.getDataBinding(type.getDataBinding()) == this) {
>> type.setDataBinding(getName());
>> type.setLogical(XMLType.UNKNOWN);
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>> I don't understand what this code is for :) What does it do?
>>
>> Would the following alternative work?
>>
>> @Override
>> public boolean introspect(DataType type, Annotation[] annotations) {
>> if (getName().equals(type.getDataBinding())) {
>> type.setLogical(XMLType.UNKNOWN);
>> return true;
>> } else {
>> return false;
>> }
>> }
>>
>> Thanks
>>
>
> or better (as it looks like data bindings can be identified by name or by
> alias)?
>
> @Override
> public boolean introspect(DataType type, Annotation[] annotations) {
> String dataBinding = type.getDataBinding();
> if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
> type.setLogical(XMLType.UNKNOWN);
> return true;
> } else {
> return false;
> }
> }
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> Hi,
>>
>> Your proposal looks good. I think it is consistent with the pattern
>> that we use to deal with unresolved models. IMO, the proxy/delegate
>> objects for databindings could be:
>>
>> DataBindingDelegate:
>> className = "my.MyDataBinding" (or ClassReference?)
>> DataBinding databinding; // transient instance lazily instantiated
>> from the class name
>> id = "db1"
>>
>> TransformerDelegate:
>> className = "my.DB12DB2Transformer"
>> Transformer instance; // transient instance lazily instantiated
>> from the class name
>> source = "DB1"
>> target = "DB2"
>> weight = 100
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jean-Sebastien Delfino"
>> <js...@apache.org>
>> To: <tu...@ws.apache.org>
>> Sent: Sunday, August 05, 2007 10:57 AM
>> Subject: Dynamic registration of databindings, was: 0.91 Memory
>> Footprint
>>
>>
>>> Jean-Sebastien Delfino wrote:
>>>> scyip12@rogers.com wrote:
>>>>> We recently migrated our version of Tuscany from M2 to 0.91, and
>>>>> we noticed that the memory consumption seems to have increased by
>>>>> quite a bit. When doing memory profiling, the culprit appeared to
>>>>> be classes related to Xerces DOM (DeferredElementNSImpl, several
>>>>> other schema element related classes). When profiling the samples
>>>>> (helloworld-ws-sdo-webapp) and our application in M2, those
>>>>> classes don't seem to get called. We are going through the jars to
>>>>> determine which module is triggering the Xerces parser, but any
>>>>> suggestions would be greatly appreciated.
>>>>>
>>>>
>>>> I'm not sure which Tuscany extension triggers the loading of Xerces
>>>> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
>>>> bindings seem to pull Xerces in their pom.xml.
>>>>
>>>> I noticed that in 0.91 most Tuscany extensions on the classpath
>>>> (and most of them are going to be on the classpath if you're using
>>>> tuscany-sca-all.jar) are aggressively loaded and initialized when
>>>> the runtime starts. I'm going to make some changes to a number of
>>>> binding and implementation extensions to allow them to be loaded
>>>> only when they are actually required by an SCA assembly.
>>>>
>>>> I hope this will help.
>>>>
>>>
>>> I looked into most of the bindings and implementations, they are now
>>> loaded dynamically, this should help with the footprint. I think we
>>> need to do the same with data bindings as they are dragging a lot of
>>> dependencies and in most cases people will stick to a single
>>> databinding in their environment.
>>>
>>> Registering databindings should be easy:
>>>
>>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>>> <databinding class name>,id=<databinding id>
>>> <databinding class name>,id=<databinding id>
>>> etc.
>>>
>>> I'm not sure about transformers, but was thinking about something
>>> like this:
>>>
>>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>>> <transformer class name>,source=<databinding id>,target=<databinding
>>> id>,weight=<weight>
>>> <transformer class name>,source=<databinding id>,target=<databinding
>>> id>,weight=<weight>
>>> etc.
>>>
>>> Thoughts?
>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>
> Most of the data binding initialization code seems to assume that data
> bindings extend BaseDataBinding by calling
> BaseDataBinding.setRegistry(...).
>
> I'm trying to understand why data bindings need to keep a pointer to
> the registry (actually the DataBindingExtensionPoint) and the only
> occurrence where it's used is in XMLStringDataBinding in:
>
> @Override
> public boolean introspect(DataType type, Annotation[] annotations) {
> if (registry.getDataBinding(type.getDataBinding()) == this) {
> type.setDataBinding(getName());
> type.setLogical(XMLType.UNKNOWN);
> return true;
> } else {
> return false;
> }
> }
>
> I don't understand what this code is for :) What does it do?
>
> Would the following alternative work?
>
> @Override
> public boolean introspect(DataType type, Annotation[] annotations) {
> if (getName().equals(type.getDataBinding())) {
> type.setLogical(XMLType.UNKNOWN);
> return true;
> } else {
> return false;
> }
> }
>
> Thanks
>
or better (as it looks like data bindings can be identified by name or
by alias)?
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
String dataBinding = type.getDataBinding();
if (NAME.equals(dataBinding) || ALIASES[0].equals(dataBinding)) {
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> Your proposal looks good. I think it is consistent with the pattern
> that we use to deal with unresolved models. IMO, the proxy/delegate
> objects for databindings could be:
>
> DataBindingDelegate:
> className = "my.MyDataBinding" (or ClassReference?)
> DataBinding databinding; // transient instance lazily instantiated
> from the class name
> id = "db1"
>
> TransformerDelegate:
> className = "my.DB12DB2Transformer"
> Transformer instance; // transient instance lazily instantiated
> from the class name
> source = "DB1"
> target = "DB2"
> weight = 100
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Sunday, August 05, 2007 10:57 AM
> Subject: Dynamic registration of databindings, was: 0.91 Memory Footprint
>
>
>> Jean-Sebastien Delfino wrote:
>>> scyip12@rogers.com wrote:
>>>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>>>> noticed that the memory consumption seems to have increased by
>>>> quite a bit. When doing memory profiling, the culprit appeared to
>>>> be classes related to Xerces DOM (DeferredElementNSImpl, several
>>>> other schema element related classes). When profiling the samples
>>>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>>>> don't seem to get called. We are going through the jars to
>>>> determine which module is triggering the Xerces parser, but any
>>>> suggestions would be greatly appreciated.
>>>>
>>>
>>> I'm not sure which Tuscany extension triggers the loading of Xerces
>>> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
>>> bindings seem to pull Xerces in their pom.xml.
>>>
>>> I noticed that in 0.91 most Tuscany extensions on the classpath (and
>>> most of them are going to be on the classpath if you're using
>>> tuscany-sca-all.jar) are aggressively loaded and initialized when
>>> the runtime starts. I'm going to make some changes to a number of
>>> binding and implementation extensions to allow them to be loaded
>>> only when they are actually required by an SCA assembly.
>>>
>>> I hope this will help.
>>>
>>
>> I looked into most of the bindings and implementations, they are now
>> loaded dynamically, this should help with the footprint. I think we
>> need to do the same with data bindings as they are dragging a lot of
>> dependencies and in most cases people will stick to a single
>> databinding in their environment.
>>
>> Registering databindings should be easy:
>>
>> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
>> <databinding class name>,id=<databinding id>
>> <databinding class name>,id=<databinding id>
>> etc.
>>
>> I'm not sure about transformers, but was thinking about something
>> like this:
>>
>> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
>> <transformer class name>,source=<databinding id>,target=<databinding
>> id>,weight=<weight>
>> <transformer class name>,source=<databinding id>,target=<databinding
>> id>,weight=<weight>
>> etc.
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
Most of the data binding initialization code seems to assume that data
bindings extend BaseDataBinding by calling BaseDataBinding.setRegistry(...).
I'm trying to understand why data bindings need to keep a pointer to the
registry (actually the DataBindingExtensionPoint) and the only
occurrence where it's used is in XMLStringDataBinding in:
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
if (registry.getDataBinding(type.getDataBinding()) == this) {
type.setDataBinding(getName());
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
I don't understand what this code is for :) What does it do?
Would the following alternative work?
@Override
public boolean introspect(DataType type, Annotation[] annotations) {
if (getName().equals(type.getDataBinding())) {
type.setLogical(XMLType.UNKNOWN);
return true;
} else {
return false;
}
}
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Your proposal looks good. I think it is consistent with the pattern that we
use to deal with unresolved models. IMO, the proxy/delegate objects for
databindings could be:
DataBindingDelegate:
className = "my.MyDataBinding" (or ClassReference?)
DataBinding databinding; // transient instance lazily instantiated from
the class name
id = "db1"
TransformerDelegate:
className = "my.DB12DB2Transformer"
Transformer instance; // transient instance lazily instantiated from the
class name
source = "DB1"
target = "DB2"
weight = 100
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Sunday, August 05, 2007 10:57 AM
Subject: Dynamic registration of databindings, was: 0.91 Memory Footprint
> Jean-Sebastien Delfino wrote:
>> scyip12@rogers.com wrote:
>>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>>> noticed that the memory consumption seems to have increased by quite a
>>> bit. When doing memory profiling, the culprit appeared to be classes
>>> related to Xerces DOM (DeferredElementNSImpl, several other schema
>>> element related classes). When profiling the samples
>>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>>> don't seem to get called. We are going through the jars to determine
>>> which module is triggering the Xerces parser, but any suggestions would
>>> be greatly appreciated.
>>>
>>
>> I'm not sure which Tuscany extension triggers the loading of Xerces yet,
>> but the SDO-Axiom and JSON databindings and the EJB and Script bindings
>> seem to pull Xerces in their pom.xml.
>>
>> I noticed that in 0.91 most Tuscany extensions on the classpath (and most
>> of them are going to be on the classpath if you're using
>> tuscany-sca-all.jar) are aggressively loaded and initialized when the
>> runtime starts. I'm going to make some changes to a number of binding and
>> implementation extensions to allow them to be loaded only when they are
>> actually required by an SCA assembly.
>>
>> I hope this will help.
>>
>
> I looked into most of the bindings and implementations, they are now
> loaded dynamically, this should help with the footprint. I think we need
> to do the same with data bindings as they are dragging a lot of
> dependencies and in most cases people will stick to a single databinding
> in their environment.
>
> Registering databindings should be easy:
>
> file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
> <databinding class name>,id=<databinding id>
> <databinding class name>,id=<databinding id>
> etc.
>
> I'm not sure about transformers, but was thinking about something like
> this:
>
> file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
> <transformer class name>,source=<databinding id>,target=<databinding
> id>,weight=<weight>
> <transformer class name>,source=<databinding id>,target=<databinding
> id>,weight=<weight>
> etc.
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Dynamic registration of databindings, was: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> scyip12@rogers.com wrote:
>> We recently migrated our version of Tuscany from M2 to 0.91, and we
>> noticed that the memory consumption seems to have increased by quite
>> a bit. When doing memory profiling, the culprit appeared to be
>> classes related to Xerces DOM (DeferredElementNSImpl, several other
>> schema element related classes). When profiling the samples
>> (helloworld-ws-sdo-webapp) and our application in M2, those classes
>> don't seem to get called. We are going through the jars to determine
>> which module is triggering the Xerces parser, but any suggestions
>> would be greatly appreciated.
>>
>
> I'm not sure which Tuscany extension triggers the loading of Xerces
> yet, but the SDO-Axiom and JSON databindings and the EJB and Script
> bindings seem to pull Xerces in their pom.xml.
>
> I noticed that in 0.91 most Tuscany extensions on the classpath (and
> most of them are going to be on the classpath if you're using
> tuscany-sca-all.jar) are aggressively loaded and initialized when the
> runtime starts. I'm going to make some changes to a number of binding
> and implementation extensions to allow them to be loaded only when
> they are actually required by an SCA assembly.
>
> I hope this will help.
>
I looked into most of the bindings and implementations, they are now
loaded dynamically, this should help with the footprint. I think we need
to do the same with data bindings as they are dragging a lot of
dependencies and in most cases people will stick to a single databinding
in their environment.
Registering databindings should be easy:
file META-INF/services/org.apache.tuscany.sca.databinding.DataBinding
<databinding class name>,id=<databinding id>
<databinding class name>,id=<databinding id>
etc.
I'm not sure about transformers, but was thinking about something like this:
file META-INF/services/org.apache.tuscany.sca.databinding.Transformer
<transformer class name>,source=<databinding id>,target=<databinding
id>,weight=<weight>
<transformer class name>,source=<databinding id>,target=<databinding
id>,weight=<weight>
etc.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: 0.91 Memory Footprint
Posted by Jean-Sebastien Delfino <js...@apache.org>.
scyip12@rogers.com wrote:
> We recently migrated our version of Tuscany from M2 to 0.91, and we noticed that the memory consumption seems to have increased by quite a bit. When doing memory profiling, the culprit appeared to be classes related to Xerces DOM (DeferredElementNSImpl, several other schema element related classes). When profiling the samples (helloworld-ws-sdo-webapp) and our application in M2, those classes don't seem to get called. We are going through the jars to determine which module is triggering the Xerces parser, but any suggestions would be greatly appreciated.
>
I'm not sure which Tuscany extension triggers the loading of Xerces yet,
but the SDO-Axiom and JSON databindings and the EJB and Script bindings
seem to pull Xerces in their pom.xml.
I noticed that in 0.91 most Tuscany extensions on the classpath (and
most of them are going to be on the classpath if you're using
tuscany-sca-all.jar) are aggressively loaded and initialized when the
runtime starts. I'm going to make some changes to a number of binding
and implementation extensions to allow them to be loaded only when they
are actually required by an SCA assembly.
I hope this will help.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org