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 > <javascript:>> 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 >> <javascript:>> 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 <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.
