On Mon, 2008-06-09 at 20:24 +0530, Samisa Abeysinghe wrote:
> Manjula Peiris wrote:
> > Seems that every one is ok with this approach. But as I mentioned this
> > approach has problems when there are multiple MTOM services. 
> 
> You mean threading issues?

No in the implementation I have specified the callback in the axis2.xml.
But when there are many services which have different callbacks then
there should be a way to specify them. We can't put this in the
services.xml becasue mime_parser does not have any information about the
services.

> 
> Thanks,
> Samisa...
> 
> > Any way I
> > will integrate the stuff when the sending side is finished.
> >
> > Thanks,
> > -Manjula.
> >
> >
> > On Mon, 2008-06-02 at 12:12 +0530, Manjula Peiris wrote:
> >   
> >> Hi all,
> >>
> >> I have developed the MTOM Caching stuff and it is almost finished in the
> >> receiving side. The implementation is here [1] as a branch. I have
> >> tested with a 160MB attachment and the results are promising. The main
> >> advantage of this implementation is it keeps a fixed user defined size
> >> of the attachment at any moment during the attachment processing. The
> >> user can implement his own callback to cache the attachment. I have
> >> included a sample callback [2] which stores the attachment in to a
> >> file. 
> >>
> >> Following are the user configurable parameters in axis2.xml.
> >>
> >> <parameter name="MTOMBufferSize" locked="false">10</parameter>
> >>
> >> Using this parameter the user can govern the caching threshold. This is
> >> in KB and I will fix this to be in MB.For example this is 10 means any
> >> attachment greater than 10KB will be cached.
> >>
> >> <parameter name="MTOMMaxBuffers" locked="false">1000</parameter>
> >>
> >> This will tell maximum numbers of buffers Axis2/C can handle when the
> >> attachment comes with a pretty large SOAP envelope. Because we are not
> >> caching the SOAP envelope.
> >>
> >>
> >> <parameter name="MTOMCachingCallback"
> >> locked="false">/path/to/your/caching_callabck</parameter>
> >>
> >> User will specify the callback name using this parameter so that Axis2/C
> >> can load when it wants to cache the attachment. If the user does not
> >> specify this the attachment will be in memory.
> >>
> >> I also added a flag called 'cached' to the axiom_data_handler. This flag
> >> will tell whether the attachment is cached or not using the user
> >> provided callback. If it is cached then it is user's responsibility in
> >> his client/service code to find the attachment, because Axis2/C cached
> >> it using his callback.
> >>
> >> I have a one major problem in this model. That is if there are more than
> >> one mtom services and if those are going to use different callbacks then
> >> we can't specify this in axis2.xml. We can't specify this in
> >> services.xml either because attachment separation happens before
> >> accessing the service. 
> >>
> >> So really appreciate your ideas regarding the above parameters, callback
> >> and the problem I have mentioned above.
> >>
> >> [1]https://svn.apache.org/repos/asf/webservices/axis2/branches/c/post_1_4_mtom/c
> >>
> >> [2]https://svn.apache.org/repos/asf/webservices/axis2/branches/c/post_1_4_mtom/c/samples/mtom_caching_callback/mtom_caching_callback.c
> >>
> >>
> >> Thanks,
> >> -Manjula 
> >>
> >>
> >>     
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >   
> > ------------------------------------------------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG. 
> > Version: 8.0.100 / Virus Database: 270.0.0/1489 - Release Date: 6/7/2008 
> > 11:17 AM
> >   
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to