Hi Christian,
I have following code snippet:
pCr is of type ConnectionRsp -- a structure to hold the request data for
mapping on 2nd invocation of access handler callback.
'parsingReqData' is set to false initially and not updated anywhere else
apart from following mentioned.
if (!pCr->parsingReqData)
{
if (upload_data_size && *upload_data_size != 0)
{
pCr->parsingReqData = true;
*ptr = pCr;
return MHD_YES;
}
else
std::cout<< "Incoming req, doesnt have data, continue..";
}
else
{
if (*upload_data_size != 0)
{
// Receive the post data and write them into the bufffer
pCr->reqData << std::string(upload_data, *upload_data_size);
*upload_data_size = 0;
return MHD_YES;
}
else
{
// *upload_data_size == 0 so all data have been received
std::cout<<"Incoming req,received data:"<<pCr->reqData.str());
pCr->parsingReqData = false;
}
}
Do you see any issue in this ?
Thanks,
Kunal
On Tue, Nov 13, 2018 at 12:05 AM Christian Grothoff <groth...@gnunet.org>
wrote:
> Hi Kunal,
>
> The most common bug in this context is that you MUST set
> "*upload_data_size = 0" (or to however many bytes are left) within your
> httpServerAccessHandlerCb. Failure to do so will mean that MHD won't
> read more of the upload. That's at least my best guess, as you only
> provided a code fragment.
>
> happy hacking!
>
> Christian
>
> On 11/12/18 2:24 PM, Kunal Ekawde wrote:
> > Hi Christian,
> >
> > I'm using following options, single threaded external epoll:
> > auto mhdDaemon = MHD_start_daemon (MHD_USE_EPOLL |
> > MHD_ALLOW_SUSPEND_RESUME | MHD_USE_ERROR_LOG |
> > *MHD_USE_TURB*O | MHD_USE_DEBUG,
> > 0,
> > NULL, NULL, &Server::httpServerAccessHandlerCb, this,
> > MHD_OPTION_SOCK_ADDR, &addr,
> > MHD_OPTION_CONNECTION_TIMEOUT, MHD_DEF_CONN_TIMEOUT,
> > MHD_OPTION_CONNECTION_LIMIT, maxConcrrntConn,
> > MHD_OPTION_EXTERNAL_LOGGER, &Server::httpServerErrorHandler,
> > this,
> > MHD_OPTION_NOTIFY_COMPLETED,
> > &Server::httpServerRequestCompleted, this,
> > MHD_OPTION_END);
> >
> > Observing that MHD is not processing the upload data for *few(other
> > request are successfully completed) *of the requests when there is data
> > associated with it. e.g PUT/GET/DELETE with data < approx 2KB.
> > logs for ref:
> > httpServerRequestCompleted:940: Request complete on txn:3522
> termCode:0\"}
> >
> > httpServerAccessHandlerCb:653: Incoming req, inserting txnId:3523 in
> > map\"} -- new request
> > httpServerAccessHandlerCb:671: Incoming req, upload data size:1607\"}
> > httpServerRequestCompleted:940: Request complete on txn:3523
> > termCode:5\"} -- doesn't process the uploaded data eventually error
> > when client(libcurl) times out.
> >
> > httpServerAccessHandlerCb:653: Incoming req, inserting txnId:3524 in
> map\"}\
> >
> > Do you see any issue ?
> >
> > Regards,
> > Kunal
> >
> >
> > On Sun, Sep 9, 2018 at 4:02 PM Christian Grothoff <groth...@gnunet.org
> > <mailto:groth...@gnunet.org>> wrote:
> >
> > On 09/06/2018 08:19 AM, Kunal Ekawde wrote:
> > >
> > > Can you please provide some information on 'MHD_USE_TURBO' as I
> > couldn't
> > > find any info in manual.
> >
> > From the manual:
> >
> > @item MHD_USE_TURBO
> > @cindex performance
> > Enable optimizations to aggressively improve performance.
> >
> > Currently, the optimizations this option enables are based on
> > opportunistic reads and writes. Bascially, MHD will simply try to
> > read or write or accept on a socket before checking that the socket
> is
> > ready for IO using the event loop mechanism. As the sockets are
> > non-blocking, this may fail (at a loss of performance), but generally
> > MHD does this in situations where the operation is likely to succeed,
> > in which case performance is improved. Setting the flag should
> > generally
> > be safe (even though the code is slightly more experimental). You
> may
> > want to benchmark your application to see if this makes any
> difference
> > for you.
> >
> >
> >
> >
> > --
> > ~Kunal
>
>
--
~Kunal
