And what I am wondering is that, if we are truly using the pull model,
should we be pulling the attachments form the stream before we hit the
service?
Looks like something is wrong.
Samisa...
Supun Kamburugamuva wrote:
Hi Manula,
I understand your point. But as Samisa said this is a service specific
configuration and I'm sure users will definitely have different
callbacks for different services. So I think we need to figure out a
way to do this configuration at the service level.
Supun..
On Mon, Jun 9, 2008 at 9:19 PM, Manjula Peiris <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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]
<mailto:[EMAIL PROTECTED]>
> >>> For additional commands, e-mail:
[EMAIL PROTECTED] <mailto:[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]
<mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[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
--
Samisa Abeysinghe
Director, Engineering; WSO2 Inc.
http://www.wso2.com/ - "The Open Source SOA Company"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
