I'm noticing now that it always seems to act as through there was a keep-alive header in the original request, even if there was not. I'm not sure if that's a big deal or not, but there is a should_keep_alive() internal function that looks like it's trying to decide if the connection should be kept alive or not.
Incidentally, that function seems to think that only connection with an endpoint type of EP_USER should be allowed to be kept alive, but when it's called in close_local_endpoint(), it checks to see if the endpoint type is EP_USER or EP_FILE. On Thursday, June 12, 2014 10:25:21 AM UTC-7, Sergey Lyubka wrote: > > Yeah that's how connection param should be used, you're correct. Don't > forget to set it back to null after dealloc. Also dealloc at mgclose to > avoid leaks. > On Jun 12, 2014 6:19 PM, "Terence Martin" <walt...@gmail.com <javascript:>> > wrote: > >> Indeed now both types of queries are treated the same. The diff on that >> is where I traced things to yesterday, even. >> >> In my simple example code, I'm using connection_param to hold the >> structure that indicates what sort of processing I'm waiting for completion >> on. >> >> So in this case, I think it's safest to dealloc and null out that >> parameter once the MG_POLL is indicating that it's done. In the best case, >> the connection is used for simple queries until it closes, and in the worst >> case it might get re-used for a second long-lived query that would >> overwrite connection_param and leak it. >> >> Many thanks for the fix and the clarification on intended behaviour. >> >> On Thursday, June 12, 2014 2:59:34 AM UTC-7, Sergey Lyubka wrote: >>> >>> I've made a quick test and realized that long-lived connections are >>> closed. >>> Pushed https://github.com/cesanta/mongoose/commit/ >>> 3cec6f6745ea9714bc77ff332072beea279bfe82 >>> Now they're kept alive. >>> Please verify. >>> >>> >>> On Thu, Jun 12, 2014 at 10:42 AM, Sergey Lyubka <val...@gmail.com> >>> wrote: >>> >>>> Hi Terence, >>>> I expect the connection to be kept alive in both cases (short-lived and >>>> long-lived requests). >>>> What does your handler return on MG_POLL event? >>>> >>>> >>>> On Wed, Jun 11, 2014 at 10:15 PM, Terence Martin <walt...@gmail.com> >>>> wrote: >>>> >>>>> I have a question regarding keep-alive connections and the MG_CLOSE >>>>> event, in particular in how they interact if you're using the >>>>> connection_param field in the mg_connection structure. >>>>> >>>>> The documentation for MG_CLOSE says: >>>>> >>>>> MG_CLOSE is sent when the connection is closed. This event is used to >>>>>> cleanup per-connection state stored in connection_param if it was >>>>>> allocated. >>>>> >>>>> >>>>> However, I have noticed that in the case of a keep-alive connection, >>>>> MG_CLOSE doesn't trigger until the idle timeout is reached (which makes >>>>> sense). This would mean that if this connection was a keep-alive and the >>>>> client issued a second request, the connection_param would still be set >>>>> as >>>>> for the previous connection. >>>>> >>>>> In my case I'm having MG_REQUEST start a query and return MG_MORE, >>>>> then using MG_POLL to check if it's complete yet and dispatch away the >>>>> results if they are. To be safe I'm discarding the structure right in the >>>>> MG_POLL once it's no longer needed and nulling the field out to make sure >>>>> that if this connection was kept-alive, the next MG_POLL wouldn't use the >>>>> structure inappropriately. >>>>> >>>>> In my limited testing it looked like simple requests (in which >>>>> MG_REQUEST returns MG_TRUE) will stay alive, while connections in which >>>>> MG_REQUEST returns MG_MORE get MG_CLOSE invoked as soon as the data is >>>>> transmitted. However, I'm not sure if that's by design, a fluke, or my >>>>> test >>>>> is doing something wonky. >>>>> >>>>> What's the best principles approach to this? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "mongoose-users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to mongoose-user...@googlegroups.com. >>>>> To post to this group, send email to mongoos...@googlegroups.com. >>>>> Visit this group at http://groups.google.com/group/mongoose-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "mongoose-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mongoose-user...@googlegroups.com <javascript:>. >> To post to this group, send email to mongoos...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/mongoose-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "mongoose-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to mongoose-users+unsubscr...@googlegroups.com. To post to this group, send email to mongoose-users@googlegroups.com. Visit this group at http://groups.google.com/group/mongoose-users. For more options, visit https://groups.google.com/d/optout.
