You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <tu...@ws.apache.org> on 2007/09/10 16:45:29 UTC
[jira] Created: (TUSCANY-1678) Would like to improve performance by
not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
---------------------------------------------------------------------------------------------------------
Key: TUSCANY-1678
URL: https://issues.apache.org/jira/browse/TUSCANY-1678
Project: Tuscany
Issue Type: Improvement
Reporter: Scott Kurz
Copying an SDO, for example, can be expensive...
The two cases I have in mind:
A) The databinding framework has done a transform which has already resulted in a copy of the data.
B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs)
Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches
the DataTransformationInteceptor.
I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole
Interceptor / invoker chain design.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-1678) Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Posted by ant elder <an...@gmail.com>.
Coincidentally i'm working on this right now, not quite finished but i'll
committed what i've done so you can say if its not doing what you need. The
relevent changes are in pass-by-value invoder out of the Java implementation
and it's now only used if there's no DB transformation, see :
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-databinding/src/main/java/org/apache/tuscany/sca/core/databinding/wire/DataBindingRuntimeWireProcessor.java
See also TUSCANY-1559 and the ML thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22959.html
...ant
On 9/10/07, Scott Kurz (JIRA) <tu...@ws.apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Scott Kurz updated TUSCANY-1678:
> --------------------------------
>
> Component/s: Java SCA Data Binding Runtime
> Affects Version/s: Java-SCA-1.0
>
> > Would like to improve performance by not doing a PBVInvoker.copy in a
> couple cases where it's unnecessary
> >
> ---------------------------------------------------------------------------------------------------------
> >
> > Key: TUSCANY-1678
> > URL: https://issues.apache.org/jira/browse/TUSCANY-1678
> > Project: Tuscany
> > Issue Type: Improvement
> > Components: Java SCA Data Binding Runtime
> > Affects Versions: Java-SCA-1.0
> > Reporter: Scott Kurz
> >
> > Copying an SDO, for example, can be expensive...
> > The two cases I have in mind:
> > A) The databinding framework has done a transform which has already
> resulted in a copy of the data.
> > B) The binding impl does a copy of the data. (For example if the
> binding impl serializes/deserializes the data in order to cross JVMs)
> > Perhaps a flag on the Message object could be used. One challenge to
> doing that would be the fact that the PBVInvoker is going to do the copy of
> the output before the output reaches
> > the DataTransformationInteceptor.
> > I don't know if there's a simple way around that. I can imagine moving
> the PBVInvoker after the DataTransformationInteceptor on the output path but
> at the expense of complication the whole
> > Interceptor / invoker chain design.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
[jira] Updated: (TUSCANY-1678) Would like to improve performance by
not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-1678:
--------------------------------
Component/s: Java SCA Data Binding Runtime
Affects Version/s: Java-SCA-1.0
> Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
> ---------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1678
> URL: https://issues.apache.org/jira/browse/TUSCANY-1678
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA Data Binding Runtime
> Affects Versions: Java-SCA-1.0
> Reporter: Scott Kurz
>
> Copying an SDO, for example, can be expensive...
> The two cases I have in mind:
> A) The databinding framework has done a transform which has already resulted in a copy of the data.
> B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs)
> Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches
> the DataTransformationInteceptor.
> I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole
> Interceptor / invoker chain design.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Assigned: (TUSCANY-1678) Would like to improve performance
by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raymond Feng reassigned TUSCANY-1678:
-------------------------------------
Assignee: Raymond Feng
> Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
> ---------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1678
> URL: https://issues.apache.org/jira/browse/TUSCANY-1678
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA Data Binding Runtime
> Affects Versions: Java-SCA-1.0
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> Copying an SDO, for example, can be expensive...
> The two cases I have in mind:
> A) The databinding framework has done a transform which has already resulted in a copy of the data.
> B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs)
> Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches
> the DataTransformationInteceptor.
> I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole
> Interceptor / invoker chain design.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-1678) Would like to improve performance
by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571635#action_12571635 ]
Raymond Feng commented on TUSCANY-1678:
---------------------------------------
The initial fix has been introduced by r628163. There are some discussions on the ML about where/how the SPI should be added.
> Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
> ---------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1678
> URL: https://issues.apache.org/jira/browse/TUSCANY-1678
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA Data Binding Runtime
> Affects Versions: Java-SCA-1.0
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> Copying an SDO, for example, can be expensive...
> The two cases I have in mind:
> A) The databinding framework has done a transform which has already resulted in a copy of the data.
> B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs)
> Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches
> the DataTransformationInteceptor.
> I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole
> Interceptor / invoker chain design.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-1678) Would like to improve performance
by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raymond Feng resolved TUSCANY-1678.
-----------------------------------
Resolution: Fixed
Add the DataExchangeSemantics SPI under r634778
> Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
> ---------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1678
> URL: https://issues.apache.org/jira/browse/TUSCANY-1678
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA Data Binding Runtime
> Affects Versions: Java-SCA-1.0
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> Copying an SDO, for example, can be expensive...
> The two cases I have in mind:
> A) The databinding framework has done a transform which has already resulted in a copy of the data.
> B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs)
> Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches
> the DataTransformationInteceptor.
> I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole
> Interceptor / invoker chain design.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1678) Would like to improve performance by
not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ant elder updated TUSCANY-1678:
-------------------------------
Fix Version/s: Java-SCA-Next
> Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
> ---------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-1678
> URL: https://issues.apache.org/jira/browse/TUSCANY-1678
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA Data Binding Runtime
> Affects Versions: Java-SCA-1.0
> Reporter: Scott Kurz
> Fix For: Java-SCA-Next
>
>
> Copying an SDO, for example, can be expensive...
> The two cases I have in mind:
> A) The databinding framework has done a transform which has already resulted in a copy of the data.
> B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs)
> Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches
> the DataTransformationInteceptor.
> I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole
> Interceptor / invoker chain design.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org