Re: [libmicrohttpd] Aync handling & message response

[Kunal Ekawde]

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 <address@hidden> 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 <address@hidden
> <mailto:address@hidden>> 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:
>
>    address@hidden MHD_USE_TURBO
>    address@hidden 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