Improve batch mechanism - 3rd try

Diff from 2nd one:
 . Integrated Andrew and Tyler's suggestion on batchIn script and function prototypes declaration in headers;
 . Fix a CMake Error on RHEL6 by preventing it to check the sanity of CXX compiler for the oBIX project
Of course, any POST request can always be raised explicitly and directly, instead of via a batch request.

The watch.pollChanges requests are handled ASYNCHRONOUSLY with the batchIn request, too costy to setup the coordination between them. Also the watch.pollChanges will wait, not a good idea to be sent through a batch request anyway (keep in mind that all batch sub commands are handled one after the other, responses won't be sent back until all of them are processed)

Harry

How did I do? 1-click feedback: https://secure.teamhively.com/welcome/rate/7672
________________________________
From: obix-devel-bounces@onedc.com [obix-devel-bounces@onedc.com] on behalf of Andrew Ross [notifications@github.com]
Sent: Thursday, October 30, 2014 11:30 AM
To: ONEDC/obix
Subject: Re: [Obix-devel] [obix] Improve batch mechanism - 3rd try (#101)


In docs/BATCH.md:

> +handlerWatchAdd | Yes
> +handlerWatchRemove | Yes
> +handlerWatchPollRefresh | Yes
> +handlerWatchPollChanges      | No
> +handlerHistoryGet | No
> +handlerHistoryQuery  | No
> +handlerHistoryAppend | No
> +handlerBatch | No
> +
> +
> +
> +In the first place, a batch request should not be allowed to nest within another otherwise a malicious batch request with thousands of level of sub batch requests nested altogether can easily consume the stack memory of relevant oBIX server thread handling such request.
> +
> +In the second place, all history handlers take care of sending back responses by themselves which are likely too massive to be sent via a batchOut contract. As a matter of fact, responses of history handlers are designed not to be sent back via obix_sever_reply_object(). Moreover, history data are sent independently from the batchOut contract, infringing relevant requirement in the oBIX specification.
> +
> +In the third place, the polling threads handling watch.pollChanges requests will compete against the oBIX server thread handling the current batch request on sending through the same FCGI request different response (the watchOut and the batchOut contract to be exact) independently and worse still, then race to release the same FCGI request which ultimately is likely to bring about a segfault.


Should we note this as a limitation? Is there a workaround? Is this a bug to be fixed in future releases?

—
Reply to this email directly or view it on GitHub<https://github.com/ONEDC/obix/pull/101/files#r19583661>.


The information contained in this email and any attachments may be confidential. This email and any attachments are also subject to copyright. No part of them may be reproduced, adapted or transmitted without the written permission of the copyright owner. If you are not the intended recipient, any use, interference with, disclosure or copying of this information is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the message from your system. All email communications to and from NEXTDC Limited are recorded for the purposes of archival and storage.