This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[12:58:00] <tbentley> temporalfox: I'd like your opinion on, because it looks to me like a rather tricky problem

[13:09:18] <temporalfox> tbentley hi

[13:11:57] <temporalfox> so it's all about the buffered messages that have been received already ?

[13:18:50] <TomBentley> temporalfox, yes that's correct [13:19:01] <temporalfox> my assumption is that we should not try to fix these [13:19:22] <temporalfox> but it should be clear in the API, that the effect takes place when the completionHandler has been called [13:19:35] <temporalfox> and in the doc [13:19:49] <TomBentley> After the completion handler has been called you mean?

[13:19:56] <temporalfox> yes

[13:20:09] <temporalfox> in the regular case (blocking API), the user polls records, so he has the same issue no ?

[13:20:26] <temporalfox> he cannot unpoll what has been fetched I guess

[13:20:39] <TomBentley> Indeed, but it's more apparent in that case because they do the poll themselves [13:20:49] <temporalfox> yes but it's an async API [13:21:05] <temporalfox> we should I think just specify it in doc [13:21:20] <TomBentley> Ok suits me

[13:21:23] <temporalfox> and say that the behavior is guaranteed in the records handler

[13:21:56] <temporalfox> and we should check that indeed if you use the records handler and change the consumer configuration, then the effect takes place in the next callback to the records handler

[13:22:24] <TomBentley> I can add tests for that [13:22:26] <temporalfox> so basically the internal command issued to reconfigure takes place before the next call to poll [13:22:34] <temporalfox> I think it should be the case already, but well -) [13:23:46] <TomBentley> Thanks, I'll put something together

[13:26:35] <temporalfox> great

[14:23:58] <tbentley> temporalfox: I think we should also document that the completion handlers for things like seek run on the worker thread, rather than the event loop thread. Since it's an exception to the vertx norm that all handlers run on the event loop thread.

[14:27:29] <mihael> hi, i am evaluating vert.x for my next project. The project consists mostly of REST services and some scheduled tasks. Data will reside inside a PostgreSQL database. What is a good project layout for this?

[17:30:34] <temporalfox> tbentley I didn't know about worker thread, what is the reason ?

[17:32:01] <tbentley> It's just the way it's been written I think. I suppose we could schedule the callback to run on the event thread once we've executed the method on the consumer from the worker thread.

[17:32:29] <tbentley> It surprised me when I noticed it temporalfox

[17:32:49] <temporalfox> I think it should be changed for consistency unless there is a particular reason

[17:33:00] <temporalfox> and that's what the user would expect

[17:33:16] <tbentley> No reason that apparent from the code.

[17:33:46] <tbentley> I'll try to open a PR, but I'm away next week… so don't hold your breath.

[17:34:02] <tbentley> I'll open an issue in the meantime, so we don't forget

[17:35:55] <tbentley>