On Mon, 2008-06-09 at 23:52 +0530, Samisa Abeysinghe wrote: > Manjula Peiris wrote: > > 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. > > > > I think the correct way to do this is to use the one given in axis2.xml > as the default and override that with one in services.xml, if there is > one provided. If the callback is set as a parameter, then this will work > seamlessly, as service level parameters override conf level params.
When we are invoking the mime_parser the service is not dispatched. So the mime_parser don't know which callback to load if it is specified in the services.xml. > > Samisa... > > > > >> 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] > > > > ------------------------------------------------------------------------ > > > > > > 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]
