You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Dennis Sosnoski (JIRA)" <ji...@apache.org> on 2006/03/26 03:59:37 UTC

[jira] Created: (AXIS2-516) MTOM forces document model generation

MTOM forces document model generation
-------------------------------------

         Key: AXIS2-516
         URL: http://issues.apache.org/jira/browse/AXIS2-516
     Project: Apache Axis 2.0 (Axis2)
        Type: Bug
  Components: databinding  
    Versions: 0.95    
 Environment: n/a
    Reporter: Dennis Sosnoski


The MTOM code currently forces the full expansion of the document model for outbound messages, in order to check for optimizable components. This contradicts the whole intent of a build-on-demand document model. Since AXIOM is actually considerably heavier in memory usage than standard DOM implementations, it also means that Axis2 performance (at least for transports supporting MTOM) is likely to be worse than the original Axis.

The performance drawbacks are especially severe when using data binding frameworks other than XMLBeans and ADB - most data binding frameworks only allow marshalling data to a stream or XMLStreamWriter equivalent, meaning that they would need to marshal the data to a memory buffer and then parse it again in order to construct the document model. This would more than eliminate any potential advantages from the use of MTOM.

One possible solution is to provide a way for data binding frameworks to check whether a value is to be "optimized" (i.e., sent out of band) at the time it is being marshalled. The data binding framework can then generate the appropriate output for an element, while the transport can handle the details of sending separate components.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


[jira] Resolved: (AXIS2-516) MTOM forces document model generation

Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/AXIS2-516?page=all ]
     
Davanum Srinivas resolved AXIS2-516:
------------------------------------

    Resolution: Fixed

Thilina removed the check that traverses the tree.

-- dims

> MTOM forces document model generation
> -------------------------------------
>
>          Key: AXIS2-516
>          URL: http://issues.apache.org/jira/browse/AXIS2-516
>      Project: Apache Axis 2.0 (Axis2)
>         Type: Bug

>   Components: databinding
>     Versions: 0.95
>  Environment: n/a
>     Reporter: Dennis Sosnoski

>
> The MTOM code currently forces the full expansion of the document model for outbound messages, in order to check for optimizable components. This contradicts the whole intent of a build-on-demand document model. Since AXIOM is actually considerably heavier in memory usage than standard DOM implementations, it also means that Axis2 performance (at least for transports supporting MTOM) is likely to be worse than the original Axis.
> The performance drawbacks are especially severe when using data binding frameworks other than XMLBeans and ADB - most data binding frameworks only allow marshalling data to a stream or XMLStreamWriter equivalent, meaning that they would need to marshal the data to a memory buffer and then parse it again in order to construct the document model. This would more than eliminate any potential advantages from the use of MTOM.
> One possible solution is to provide a way for data binding frameworks to check whether a value is to be "optimized" (i.e., sent out of band) at the time it is being marshalled. The data binding framework can then generate the appropriate output for an element, while the transport can handle the details of sending separate components.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira