You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Thomas Boniface <th...@stickyads.tv> on 2015/12/17 18:20:22 UTC

Zero Copy JSON serialization

Hi,

I would like to save as much resource as possible while sending JSON
requests using an http async client.

I tried to implement my own HttpEntity hoping I could force jackson
serialization directly in the ouputsteam :

    @Override
    public void writeTo(OutputStream outstream) throws IOException {
        objectMapper.writeValue(outstream, bidRequest);
    }

Unfortunetly the client seems to pull the content to send from the
getContent method of the http entity. Using this method would force me to
first serialize my JSON objects into a byte array an create an inputsteam
from it. This may be better than serializing to a String and use and
StringEntity but it feels like there is still room for optimization.

I saw a ZeroCopyPost but dedicated to files, is there a built in feature to
achive what I'm looking for (Zero copy post for in memory object) ?

Thanks in advance

Thomas

Re: Zero Copy JSON serialization

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-12-18 at 20:39 +0100, Thomas Boniface wrote:
> Thanks for your reply Oleg. It does help a bit but my question was probably
> not 100% clear, I think I used stream (just like zero copy) incorrectly.
> 
> What I'm trying to achieve is limiting the number of intermediary objets
> between my in memory object and what is sent in the http body. I created a
> custom HttpEntity that allows me to only serialize the object when the http
> clients needs the content that's already a good performance improvement I
> think but I wondered if I could serialize my object (using jackson) to an
> outputstream using the HttpAsyncContentProducer.
> 
> Thomas
> 

Thomas

InputStream / OutputStream / Reader / Writer based APIs are inherently
blocking. They cannot be used with HttpAsyncClient without a certain
loss of efficiency. 

Oleg


> 2015-12-18 10:45 GMT+01:00 Oleg Kalnichevski <ol...@apache.org>:
> 
> > On Thu, 2015-12-17 at 18:20 +0100, Thomas Boniface wrote:
> > > Hi,
> > >
> > > I would like to save as much resource as possible while sending JSON
> > > requests using an http async client.
> > >
> > > I tried to implement my own HttpEntity hoping I could force jackson
> > > serialization directly in the ouputsteam :
> > >
> > >     @Override
> > >     public void writeTo(OutputStream outstream) throws IOException {
> > >         objectMapper.writeValue(outstream, bidRequest);
> > >     }
> > >
> > > Unfortunetly the client seems to pull the content to send from the
> > > getContent method of the http entity. Using this method would force me to
> > > first serialize my JSON objects into a byte array an create an inputsteam
> > > from it. This may be better than serializing to a String and use and
> > > StringEntity but it feels like there is still room for optimization.
> > >
> > > I saw a ZeroCopyPost but dedicated to files, is there a built in feature
> > to
> > > achive what I'm looking for (Zero copy post for in memory object) ?
> > >
> > > Thanks in advance
> > >
> > > Thomas
> >
> > Thomas
> >
> > The term zero-copy applies only to socket to file or file to socket data
> > transfer.
> >
> > If you want to write out any arbitrary request content you should
> > implement a custom HttpAsyncContentProducer if none of the standard ones
> > suit your needs. With content-length delineated connections one can
> > effectively stream data directly to the underlying TCP channel.
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Re: Zero Copy JSON serialization

Posted by Thomas Boniface <th...@stickyads.tv>.
Thanks for your reply Oleg. It does help a bit but my question was probably
not 100% clear, I think I used stream (just like zero copy) incorrectly.

What I'm trying to achieve is limiting the number of intermediary objets
between my in memory object and what is sent in the http body. I created a
custom HttpEntity that allows me to only serialize the object when the http
clients needs the content that's already a good performance improvement I
think but I wondered if I could serialize my object (using jackson) to an
outputstream using the HttpAsyncContentProducer.

Thomas

2015-12-18 10:45 GMT+01:00 Oleg Kalnichevski <ol...@apache.org>:

> On Thu, 2015-12-17 at 18:20 +0100, Thomas Boniface wrote:
> > Hi,
> >
> > I would like to save as much resource as possible while sending JSON
> > requests using an http async client.
> >
> > I tried to implement my own HttpEntity hoping I could force jackson
> > serialization directly in the ouputsteam :
> >
> >     @Override
> >     public void writeTo(OutputStream outstream) throws IOException {
> >         objectMapper.writeValue(outstream, bidRequest);
> >     }
> >
> > Unfortunetly the client seems to pull the content to send from the
> > getContent method of the http entity. Using this method would force me to
> > first serialize my JSON objects into a byte array an create an inputsteam
> > from it. This may be better than serializing to a String and use and
> > StringEntity but it feels like there is still room for optimization.
> >
> > I saw a ZeroCopyPost but dedicated to files, is there a built in feature
> to
> > achive what I'm looking for (Zero copy post for in memory object) ?
> >
> > Thanks in advance
> >
> > Thomas
>
> Thomas
>
> The term zero-copy applies only to socket to file or file to socket data
> transfer.
>
> If you want to write out any arbitrary request content you should
> implement a custom HttpAsyncContentProducer if none of the standard ones
> suit your needs. With content-length delineated connections one can
> effectively stream data directly to the underlying TCP channel.
>
> Hope this helps
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>

Re: Zero Copy JSON serialization

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2015-12-17 at 18:20 +0100, Thomas Boniface wrote:
> Hi,
> 
> I would like to save as much resource as possible while sending JSON
> requests using an http async client.
> 
> I tried to implement my own HttpEntity hoping I could force jackson
> serialization directly in the ouputsteam :
> 
>     @Override
>     public void writeTo(OutputStream outstream) throws IOException {
>         objectMapper.writeValue(outstream, bidRequest);
>     }
> 
> Unfortunetly the client seems to pull the content to send from the
> getContent method of the http entity. Using this method would force me to
> first serialize my JSON objects into a byte array an create an inputsteam
> from it. This may be better than serializing to a String and use and
> StringEntity but it feels like there is still room for optimization.
> 
> I saw a ZeroCopyPost but dedicated to files, is there a built in feature to
> achive what I'm looking for (Zero copy post for in memory object) ?
> 
> Thanks in advance
> 
> Thomas

Thomas

The term zero-copy applies only to socket to file or file to socket data
transfer. 

If you want to write out any arbitrary request content you should
implement a custom HttpAsyncContentProducer if none of the standard ones
suit your needs. With content-length delineated connections one can
effectively stream data directly to the underlying TCP channel.  

Hope this helps

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org