If you feel that the improvement can be done without a breaking change to the current configuration options somehow then I'm not opposed with this targetting 3.4.x and the deprecation of the old settings.
On Tue, Mar 19, 2019 at 1:07 AM Divij Vaidya <[email protected]> wrote: > 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 > > > > > >
