Re: Possible bug in Http11Processor/SocketWrapperBase

[Michael Osipov]

Am 2019-10-11 um 17:06 schrieb Mark Thomas:

On 11/10/2019 13:21, Michael Osipov wrote:

Folks,

while working on BZ-63835 I have noticed an odd thing and I'd like
someone to review whether my code/understanding is wrong or the one
already present in Tomcat.





we have a total of 100 requests (HTTP/1.1 302).


That is consistent with the docs that state there will be
maxKeepAliveRequests before the connection is closed.


I'd assume the
connection to sustain 100 requests and on the n+1 requests to be closed.


That assumption is not consistent with the documentation (which has been
the same for as long as I can remember).


I have just reread the documentation in Tomcat and in HTTPd. They both 
sound similiar, but why are both differntly implemented? Would you say 
that bouth have a different intepretation and neither is wrong?


I tend to agree with your that if 100 is send 100 is max, and not 100 + 1.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Private branches in the official Tomcat git repository

[Michael Osipov]

Am 2019-10-12 um 15:57 schrieb Konstantin Kolinko:

пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat :


Hi,

This vote is to regulate the use of branches in the official Tomcat repository 
beyond branches that are approved by the community such as 8.5.x and 7.0.x. It 
is possible to do development in private branches directly in the official 
Tomcat repository, as an alternative to using forks and pull requests.

Should private branches be allowed in the official Tomcat git repository ?
[x] Yes
[ ] No


Certainly Yes. We must be able to conduct our business without relying
on GitHub and without relying on its pull requests.


+1


If we call them not "private" branches, but "feature" branches - your
email concerns will be the same, but many projects are using feature
branches.


I agree that titling a commit as "First draft" is a bad naming. I
would like to see more elaborated commit message, with more context in
it.

If you remember when we were using Subversion, feature branches were
used several times. E.g. I used them to backport testing framework to
Tomcat 6. It generated a lot of emails, but their Subject line
contained the root path of the commit, and in Subversion such path
includes a branch name.


It is the very same approach. I am working same as before on features 
under a Bugzilla issue id. This is not intended to be a playground.



As a big github user, i expect main repo to not have unofficially supported 
code.


Technically, the only supported code are the official releases that
have passed a vote. Anything else is a work in progress.


+1


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Private branches in the official Tomcat git repository

[Felix Schumacher]

Am 11.10.19 um 16:43 schrieb Rémy Maucherat:
> On Fri, Oct 11, 2019 at 4:30 PM Michael Osipov  > wrote:
>
> Am 2019-10-11 um 16:20 schrieb Rémy Maucherat:
> > Hi,
> >
> > This vote is to regulate the use of branches in the official Tomcat
> > repository beyond branches that are approved by the community
> such as 8.5.x
> > and 7.0.x. It is possible to do development in private branches
> directly in
> > the official Tomcat repository, as an alternative to using forks
> and pull
> > requests.
> >
> > Should private branches be allowed in the official Tomcat git
> repository ?
> > [ ] Yes
> > [ ] No
>
> I don't like the term 'private' because everytihing I add to the
> canonical repo is intended to merged into upstream sooner or later.
> Purely private stuff must be in a fork anyway.
>
> Please redefine.
>
>
> Well, it's already in the text of the vote ("This vote is to regulate
> the use of branches in the official Tomcat repository beyond branches
> that are approved by the community such as 8.5.x and 7.0.x"): Private
> branches are defined here as any branches whose creation is not
> approved and voted on by the community.
>
> = I feel like creating branch "remm", is it allowed ?
> So I say no, because this is the Tomcat repo, not remm's repo, even
> though commits could possibly be interesting this is a bit too much.

In that sense, I would say "no", too. There is no need for a private
only branch with git.

For feature branches - which I understand are out of scope for this - I
would be tending towards a "yes".

Felix

>
> Rémy
>  
>
>
> In that case as depicted by me:
> Yes!
>

Re: [VOTE] Private branches in the official Tomcat git repository

[Guoxiong Li]

>  If we call them not "private" branches, but "feature" branches
The "feature" branches is a better name to state these branches.

If the feature branch could be created and named after passing a vote
which could prevent excessive branches and bad branch name, the
branches would be better managed.

On Sat, Oct 12, 2019 at 9:57 PM Konstantin Kolinko 
wrote:

> пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat :
> >
> > Hi,
> >
> > This vote is to regulate the use of branches in the official Tomcat
> repository beyond branches that are approved by the community such as 8.5.x
> and 7.0.x. It is possible to do development in private branches directly in
> the official Tomcat repository, as an alternative to using forks and pull
> requests.
> >
> > Should private branches be allowed in the official Tomcat git repository
> ?
> > [x] Yes
> > [ ] No
>
> Certainly Yes. We must be able to conduct our business without relying
> on GitHub and without relying on its pull requests.
>
> If we call them not "private" branches, but "feature" branches - your
> email concerns will be the same, but many projects are using feature
> branches.
>
>
> I agree that titling a commit as "First draft" is a bad naming. I
> would like to see more elaborated commit message, with more context in
> it.
>
> If you remember when we were using Subversion, feature branches were
> used several times. E.g. I used them to backport testing framework to
> Tomcat 6. It generated a lot of emails, but their Subject line
> contained the root path of the commit, and in Subversion such path
> includes a branch name.
>
> > As a big github user, i expect main repo to not have unofficially
> supported code.
>
> Technically, the only supported code are the official releases that
> have passed a vote. Anything else is a work in progress.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Private branches in the official Tomcat git repository

[Romain Manni-Bucau]

Le sam. 12 oct. 2019 à 15:57, Konstantin Kolinko  a
écrit :

> пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat :
> >
> > Hi,
> >
> > This vote is to regulate the use of branches in the official Tomcat
> repository beyond branches that are approved by the community such as 8.5.x
> and 7.0.x. It is possible to do development in private branches directly in
> the official Tomcat repository, as an alternative to using forks and pull
> requests.
> >
> > Should private branches be allowed in the official Tomcat git repository
> ?
> > [x] Yes
> > [ ] No
>
> Certainly Yes. We must be able to conduct our business without relying
> on GitHub and without relying on its pull requests.
>
> If we call them not "private" branches, but "feature" branches - your
> email concerns will be the same, but many projects are using feature
> branches.
>
>
> I agree that titling a commit as "First draft" is a bad naming. I
> would like to see more elaborated commit message, with more context in
> it.
>
> If you remember when we were using Subversion, feature branches were
> used several times. E.g. I used them to backport testing framework to
> Tomcat 6. It generated a lot of emails, but their Subject line
> contained the root path of the commit, and in Subversion such path
> includes a branch name.
>
> > As a big github user, i expect main repo to not have unofficially
> supported code.
>
> Technically, the only supported code are the official releases that
> have passed a vote. Anything else is a work in progress.
>

Read it as "external corrupted code".
While only committers can push branches it is fine for me.


> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Private branches in the official Tomcat git repository

[Konstantin Kolinko]

пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat :
>
> Hi,
>
> This vote is to regulate the use of branches in the official Tomcat 
> repository beyond branches that are approved by the community such as 8.5.x 
> and 7.0.x. It is possible to do development in private branches directly in 
> the official Tomcat repository, as an alternative to using forks and pull 
> requests.
>
> Should private branches be allowed in the official Tomcat git repository ?
> [x] Yes
> [ ] No

Certainly Yes. We must be able to conduct our business without relying
on GitHub and without relying on its pull requests.

If we call them not "private" branches, but "feature" branches - your
email concerns will be the same, but many projects are using feature
branches.


I agree that titling a commit as "First draft" is a bad naming. I
would like to see more elaborated commit message, with more context in
it.

If you remember when we were using Subversion, feature branches were
used several times. E.g. I used them to backport testing framework to
Tomcat 6. It generated a lot of emails, but their Subject line
contained the root path of the commit, and in Subversion such path
includes a branch name.

> As a big github user, i expect main repo to not have unofficially supported 
> code.

Technically, the only supported code are the official releases that
have passed a vote. Anything else is a work in progress.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63833

--- Comment #6 from Konstantin Kolinko  ---
(In reply to Christopher Schultz from comment #4)

It is much better to keep discussion in one place in Bugzilla, rather than
scattered among maybe several PRs.

I was wondering why this bug report is against Tomcat instead of the upstream
Apache Commons DBCP project, by Phil Steitz's comment 2 gives an explanation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63833

--- Comment #5 from Guoxiong Li  ---
I once submitted a PR to solve a issue. But the PR was not good enough to merge
so that the committer solved the issue by himself and closed my PR without
merging. As a result, I attach the patch to this BZ for committers to review
and comment this time so that I can modify my patch and avoid my PR to be
rejected.

It is better for committer to comment, give some recommendation and let the PR
submitter to modify the PR instead of doing similar thing by themselves after
reviewing the PR.

Maybe the situation of my previous PR happened by accident and is not the
typical review process. I will choose only one way(patch or PR) to contribute
in the future according to your suggestion which could avoid repeat. In this
BZ, I will just use the patch file and won't use PR.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63835] Add support for Keep-Alive header

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63835

--- Comment #6 from Michael Osipov  ---
(In reply to Mark Thomas from comment #5)
> The proposal never went past draft 03 in 2012. I'm wondering why.

Me too.

> The max parameter is already deprecated in draft 03. I don't think Tomcat
> should be implementing a deprecated feature of a draft proposal without a
> very good reason and I can't see one at this point.

Agreed, I will happily drop max parameter.

> I can see the timeout could be useful in avoiding sending a request just as
> the server was closing the connection, triggering a TCP reset and a need to
> resend the request. However, for that to work the client needs a reasonable
> estimate of the latency between the client and the server and that isn't
> always available.

Not only latency, you can dynamically adjust your connection pool to that and
avoid broken connections. Apache HttpClient does that.

> That it is intended to send this header only when the client sends
> "Connection: keep-alive" doesn't really change things. Browsers usually send
> that. Having to parse the request header and likely generate the response
> header adds overhead to every request. It would be useful to have a sense of
> the scale of that overhead.

The Connection header is parsed anyway with isConnectionClose() already.
Getting an integer from the socket wrapper seems easy. I could at most add
nanoTime before and after and have a look at these numbers, but I doubt that it
will really consume time. WDYT?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63833

--- Comment #4 from Christopher Schultz  ---
Both reviews and edits can all be done in a PR. Why attach successive patches
to this BZ issue when you plan in issuing a PR anyway?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Private branches in the official Tomcat git repository

[Rainer Jung]

Am 11.10.2019 um 16:20 schrieb Rémy Maucherat:

Hi,

This vote is to regulate the use of branches in the official Tomcat 
repository beyond branches that are approved by the community such as 
8.5.x and 7.0.x. It is possible to do development in private branches 
directly in the official Tomcat repository, as an alternative to using 
forks and pull requests.


Should private branches be allowed in the official Tomcat git repository ?
[ ] Yes
[X] No


Regards,

Rainer


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Private branches in the official Tomcat git repository

[Romain Manni-Bucau]

[No] (non binding). As a big github user, i expect main repo to not have
unofficially supported code. I work with this kind of setup (for CI) and it
is a mess at all layers compared to natural PR structure IMHO.

Le sam. 12 oct. 2019 à 02:05, Chuck Caldarale  a écrit :

> On Oct 11, 2019, at 09:20, Rémy Maucherat  wrote:
>
> > This vote is to regulate the use of branches in the official Tomcat
> > repository beyond branches that are approved by the community
> > such as 8.5.x and 7.0.x. It is possible to do development in private
> > branches directly in the official Tomcat repository, as an alternative
> > to using forks and pull requests.
>
> > Should private branches be allowed in the official Tomcat git repository
> ?
> [ ] Yes
> [x] No
>
> I’m not a committer, so my vote doesn’t really count, but I am a long-time
> Tomcat user and occasional contributer (less these days due to work
> priorities). I find the use of personal branches in the public repository
> to be at best annoying.
>
>   - Chuck
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=63833

Guoxiong Li  changed:

   What|Removed |Added

  Attachment #36823|0   |1
is obsolete||

--- Comment #3 from Guoxiong Li  ---
Created attachment 36824
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36824=edit
A new draft patch for review.

Hi Phil Steitz, think your for your reminding. I update my patch. 

The new patch add null check in method destroyObject. I don't modify method
activateObject, validateConnection and passivateObject because I consider that
a patch should minumize and avoid too many changes.

When the reviewer agree to the change and the test method in this path, I will
add another patch which changes the method activateObject, validateConnection
and passivateObject. I will squash all the commit and submit a pull request
which make it easy to merge.

Please review the patch. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org