Hi,
> Yes while we are parsing the stream depending on the size write it to a
> file or keep it on memory. This parsing happens at very early stages of
> request processing at the transport level even before invoking the
> engine. The data_handler has a reference to the attachment if it is in
> me
On Tue, 2008-06-10 at 11:03 -0700, Thilina Gunarathne wrote:
> Hi,
>
> On Tue, 2008-06-10 at 16:46 +0530, Samisa Abeysinghe wrote:
> > And what I am wondering is that, if we are truly using the
> pull model,
> > should we be pulling the attachments form the
Hi,
>
> On Tue, 2008-06-10 at 16:46 +0530, Samisa Abeysinghe wrote:
> > 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?
>
> In order to do this we may need to stop parsing the incoming st
On Tue, 2008-06-10 at 16:46 +0530, Samisa Abeysinghe wrote:
> 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?
In order to do this we may need to stop parsing the incoming stream
after we f
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
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
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 w
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 th
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
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?
Thanks,
Samisa...
Any way I
will integrate the stuff when the sending side is finished.
Thanks,
-Manjula.
O
Seems that every one is ok with this approach. But as I mentioned this
approach has problems when there are multiple MTOM services. 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 ha
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 a
12 matches
Mail list logo
