Thanks for your perusal of the proposal. I agree that a benchmark is required to measure the impact of this change. Will ensure it is added with the PR.
However, I think that this change should be a candidate of 3.4.x series so that the benefits of this change could be harnessed as soon as possible (since, as you mentioned 3.5.x release timeline is not set right now). To make this change transparent to the end users of 3.4.x, we would have backward compatible code with the existing configuration. This would be achieved by maintaining the max concurrency that the customer wanted to achieve using the existing settings. As an example, if the current setting is maxSimultaneousUsage = 32, maxConnectionPoolSize = 32, clearly, the customer is trying to achieve a throughput of 32*32 = 1024 simultaneous requests. The new code will calculate the maxConnectionPoolSize (which is 1:1 with each request) as maxConnectionPoolSize = Max(InProcess , SimutaneousUsage) * maxConnectionPoolSize. Let me know what do you think about this. Divij Vaidya On Mon, Mar 18, 2019 at 9:16 AM Stephen Mallette <[email protected]> wrote: > Thanks for taking the time to make this proposal. At this time, I don't > really have an strong opinions on how connection pools should work - I will > think on it some more this week. I'd agree that the driver is hard to > configure and perhaps all that flexibility that currently exists results in > too much low-level knob turning that is hard for the average user to reason > about. So a more simple set of configuration options and hopefully a more > simple to maintain code base without (1) a noticeable loss in performance > or (2) breaking change in protocol would probably be well received by the > community. I think it would be important for a PR of this scope to have > some performance comparisons presented when the changes are in place and > ready for a PR to review. > > I sense that as this is a large change that it should slate for 3.5.0 > (which we really haven't even begun to plan yet, but perhaps this is the > catalyst to start talking about that). > > > On Fri, Mar 15, 2019 at 9:36 PM Divij Vaidya <[email protected]> > wrote: > > > Hello all, > > > > I would like to propose an implementation change on the Gremlin Java > > client. The change impacts the connection pool management and > configuration > > of the client. The following document discusses the problems that the > > change is trying to address along with the proposed solution. > > > > > > > https://docs.google.com/document/d/1MG6dx-h-lfmc6d469ZXfDBeGM_ivBcWi7sziC-jLJNw/edit?usp=sharing > > > > Kindly review the document and let me know about your > suggestions/concerns. > > > > Once the proposal is approved, I will work on the implementation of the > > proposal and file a pull request with the relevant code changes. > > > > Regards, > > Divij Vaidya > > >
