> On Mon, 2009-09-21 at 14:46 -0400, Raymond Dans wrote: > > 2. HttpServer only solution: Add a check in the read to detect a 0 > byte > > read return value and not proceed to pass the request to supervisor > for > > processing. Problem with this solution is that there are other cases > > where 0 bytes can be returned (without closing the socket) and we > should > > send a response back indicating an error in the request. > > > > 3. HttpMessage/HttpServer solution: Modify HttpMessage to NOT close > the > > socket in the case of exceeding the maximum content length but return > > some error value (< 0). Modify HttpServer to detect the error on the > > HttpMessage read and construct an appropriate response that is then > > returned. > > > > 4. HttpServer-2 solution: Same as #2 but also add a check to see if > the > > socket is still open. If not, don't send a response back at all. > > It's clear that we need a better strategy if a malformed XML-RPC is > received. (1) At the least, if HttpServer attempts to send a response > and the socket is closed, it should not cause a core dump. (2) If the > incoming message to HttpServer is malformed to the point that we cannot > clearly identify the end of the message (and thus the beginning of the > next one), we should close the socket. (3) I'm not sure what > processing > should be done in the XMLRPC context if a malformed request is > received. > > > 5. sipXconfig solution: Instead of sending extremely large > replications > > in 1 request, break them up into smaller chunks and use the > appropriate > > XML-RPC method that adds the records to an IMDB as opposed to calling > > the method (replace) which clears the existing IMDB and then adds all > of > > the records (this of course assumes that all records are in the > > request). > > We will need to do something like that if we are to handle a large > number of users. But I think the problem is probably worse that what > you describe -- sending many users in small chunks will leave a long > time when most of the users are not in the target IMDB. It would be > better to either (1) assemble the entire set of users in a temporary > space at the destination, then use a quick operation to replace the > IMDB > contents, or (2) in some manner, send the deltas between the current > IMDB and the desired IMDB, and apply them through inserts/deletes, > rather than mass-delete followed by mass-insert. > > Dale
Just for curiosity sake how large are the XML-RPC requests? (size) I am getting the feeling this is extremely large. > > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
