You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/11/04 16:11:24 UTC
Long-standing ServerConnection bug
This is one of those bugs that has been around for so long that everyone
just looks at it and thinks that it is working properly ... :-)
In ServerConnection, we call serverSocket.accept(), and *then* process
whether or not we have hit the configured limit for accepted sockets.
Doesn't this defeat the purpose for having a TCP/IP backlog? AFAICS, yes,
it defeats the purpose for the queue and wastes considerable CPU cycles
doing so. Shouldn't we invoke accept() only if we are not already at the
threshold (as simple as limiting the number of accept() calls to the
configured limit)?
--- Noel
cc: Peter, who worked on the current code, to get his thoughts, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Long-standing ServerConnection bug
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara wrote:
> So imo this is ok: why did you add "10000" instead of "unlimited" wait()
> ? Is it only "defensive" programming or there are cases where an
> unlimited wait do not work?
Ok, I must be blind. I see you already explained it in the commit log ;-)
So everything is clear, and right!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> why did you add "10000" instead of "unlimited" wait() ?
> Is it only "defensive" programming or there are cases
> where an unlimited wait do not work?
Purely defensive programming. It can be tightened up/eliminated as we have
more time to work on it, but I'd rather code it defensively than run into a
race condition. :-) And I'm sure that there is the potential for a race
condition in the current code, so I used the defensive approach.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Long-standing ServerConnection bug
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> Noel J. Bergman wrote:
>>>> check the limit in addClientConnectionRunner to stop the thread if
>>>> the limit has been reached and to restart the listening thread in
>>>> removeClientConnectionRunner if we are stopped?
>>> No, I'd prefer to avoid a change of that nature.
>> Can you explain
>
> It depends upon what you mean. If you mean stop and restart, then what I
> did in the current code does what you want. We "stop the thread" by calling
> wait(), and the client "restarts the listening thread in
> removeClientConnectionRunner" by calling notify(). If you mean terminate
> and recreate, then ...
You are right.
Sorry, I reviewed the code you committed only now and I see you added
the notify/wait code.
So imo this is ok: why did you add "10000" instead of "unlimited" wait()
? Is it only "defensive" programming or there are cases where an
unlimited wait do not work?
> Architecturally, JAMES has a single thread per ServerConnection (listening
> service) that accepts messages and doles them out to worker threads from the
> pool. Changing that so that the listener thread terminates, and is
> re-created whenever there is room in the pool would be a signficant change
> to the way the system works. It introduces overhead, seems entirely
> unnecessary, and doesn't introduce any simplicity to the architecture.
>
> --- Noel
I was focused on your first proposal and I did not see that you finally
committed a wait/notify solution that I like. I agree that your solution
is simpler than stopping the thread and starting a new one.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
>>> check the limit in addClientConnectionRunner to stop the thread if
>>> the limit has been reached and to restart the listening thread in
>>> removeClientConnectionRunner if we are stopped?
>> No, I'd prefer to avoid a change of that nature.
> Can you explain
It depends upon what you mean. If you mean stop and restart, then what I
did in the current code does what you want. We "stop the thread" by calling
wait(), and the client "restarts the listening thread in
removeClientConnectionRunner" by calling notify(). If you mean terminate
and recreate, then ...
Architecturally, JAMES has a single thread per ServerConnection (listening
service) that accepts messages and doles them out to worker threads from the
pool. Changing that so that the listener thread terminates, and is
re-created whenever there is room in the pool would be a signficant change
to the way the system works. It introduces overhead, seems entirely
unnecessary, and doesn't introduce any simplicity to the architecture.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Long-standing ServerConnection bug
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> check the limit in addClientConnectionRunner to stop the thread if
>> the limit has been reached and to restart the listening thread in
>> removeClientConnectionRunner if we are stopped?
>
> No, I'd prefer to avoid a change of that nature.
>
> --- Noel
Can you explain?
I think that the solution would be better from a technical perspective,
and since we are un trunk it should not be so harmful.
I'm not asking you to do this, but I want to know what are the
justifications of the "I'd prefer to avoid" so I know if an effort from
someone else to use that method would be good, or you have some specific
concern about that solution.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
> check the limit in addClientConnectionRunner to stop the thread if
> the limit has been reached and to restart the listening thread in
> removeClientConnectionRunner if we are stopped?
No, I'd prefer to avoid a change of that nature.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Long-standing ServerConnection bug
Posted by Stefano Bagnara <ap...@bago.org>.
What do you propose?
To check the limit in addClientConnectionRunner to stop the thread if
the limit has been reached and to restart the listening thread in
removeClientConnectionRunner if we are stopped?
Stefano
Noel J. Bergman wrote:
> This is one of those bugs that has been around for so long that everyone
> just looks at it and thinks that it is working properly ... :-)
>
> In ServerConnection, we call serverSocket.accept(), and *then* process
> whether or not we have hit the configured limit for accepted sockets.
> Doesn't this defeat the purpose for having a TCP/IP backlog? AFAICS, yes,
> it defeats the purpose for the queue and wastes considerable CPU cycles
> doing so. Shouldn't we invoke accept() only if we are not already at the
> threshold (as simple as limiting the number of accept() calls to the
> configured limit)?
>
> --- Noel
>
> cc: Peter, who worked on the current code, to get his thoughts, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Danny Angus <da...@gmail.com>.
On 11/7/06, Stefano Bagnara <ap...@bago.org> wrote:
> Don't know what others think, but I have a few workflow problems working
> on the STATUS file (I would prefer, for example, a wiki page).
> I would like to hear what other committers think about this, as I would
> not like to be the only one updating it: I'm not the owner of any open
> branch, but I just updated it to include some of them.
It is a matter of having a controlled record of what decisions we've
made, people who are driving out decisions will have more record
keeping to do, thats just life I'm afraid. And updating the STATUS
file isn't really much more difficult than updating a wiki page or
sending an email.
>
> I personally don't need a status file because I spend already so much
> time on this project that it is more probable I forgot my name than the
> status of the project, and I currently feel I'm updating it to make
> Danny happy...
No, you should be doing it to record the fact that *other people* have
endorsed what you are doing, This is a collaboration and it is
important to record our consensus, especially important to people in
your position who might be accused of doing too much too quickly
without the support of the group. The STATUS file is there to back you
up.
> I really have problems deciding what to write there and what to not
> write there. I would write there every message I wrote in the "roadmaps"
> threads but this would make it unreadable... so I don't write much...
No, just key facts, what version, when. If you *want to* you can add
*short* descriptions of what is planned for the versions, and record
VOTES which people might question. You're finding that it is hard to
keep reminding people that they have agreed to something. The STATUS
file should help stop that.
> That said I will update it when you'll write "this should be in the
> status file" ;-) . And maybe you can do this for a while so I learn.
I hope you will learn that it can benefit you by being your sword and
shield as well ;-)
And if it really doesn't help us with some of this stuff, well we can
stop using it again.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> Guys,
>
> Standing up for Stefano here..
>
> On 11/4/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Sorry I don't understand this message. I understood we defined the
>> following:
>>
>> 2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
>> release something if needed (the unbounded cache and the connection
>> accepting problem are good candidate to decide we need it).
>>
>> next-minor: the release you said you want to work and that will be based
>> on 2.3 branch (but not the 2.3 branch itself) and you want to backport
>> things from trunk (to be released in 1-2 months).
>>
>> next-major: the release we are currently preparing on trunk and that
>> we'll branch soon (in 1-2 months).
>
> This is (or should be) reflected in the STATUS file.
> (yeah STATUS file!)
>
> d.
I just updated it.
Don't know what others think, but I have a few workflow problems working
on the STATUS file (I would prefer, for example, a wiki page).
I would like to hear what other committers think about this, as I would
not like to be the only one updating it: I'm not the owner of any open
branch, but I just updated it to include some of them.
I personally don't need a status file because I spend already so much
time on this project that it is more probable I forgot my name than the
status of the project, and I currently feel I'm updating it to make
Danny happy...
I really have problems deciding what to write there and what to not
write there. I would write there every message I wrote in the "roadmaps"
threads but this would make it unreadable... so I don't write much...
That said I will update it when you'll write "this should be in the
status file" ;-) . And maybe you can do this for a while so I learn.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> Well, I believe in you, but I also know that you are the only supporter
>> of the "next-minor"
>
> Actually not, but I believe that you've talked most people to death on it.
> That doesn't work on me.
This is a major issue. No one voted something different than +0 to the
next-minor vote. I believe I didn't write false statement and that the
vote was fair. If you think this is not true please start a vote NOW.
Please do it or accept that you are the only active supporter of that
release: there is nothing wrong in being alone acrively supporting a
release, I did it for 1 year.
Please don't tell me that I should not discuss now: you all asked me to
discuss much more when I was committing. If I can't discuss and I can't
commit maybe I should better leave the project ;-)
>> and you are so busy that you have to vote on the "James Server future
>> releases/road maps" vote I started in October the 25th.
>
> Actually, I just prioritize my time. First, I was at a conference, and then
> I was fixing fictional bugs because my production server shared my
> delusions.
This is what everyone do: I lost money in the last year to fix bugs in
james 2.3.0, most time bugs on code I didn't write. I could have skipped
bug fixes to work on new features, but this sentences seems to me a bit
off-topic.
>> So I think it is safer for the project if we keep open the way to
>> a 2.3.1 in case you'll be busier than you think now and we have to
>> cancel next-minor.
>
> My time to waste.
?
I can offer myself ot mantain 2.3.1, so it will not be more time for
you. And if you know what you are doing on next-minor I bet you won't
waste your time.
Being alone on that branch make you almost the only responsible people
for his own time: if you'll succeed with the next-minor featureset (you
for sure understand that is not clear what will be included there) and
its release dates everyone here will be happy and your time won't be wasted.
>> The doubts you later expose about "next-major" are the same doubts I
>> have about your next-minor: I understood you want handlerapi-v2 in
>> "next-minor"
>
> In the first out? I doubt it. Ever? That would all depend on just how bad
> the code is that comes over from trunk.
This is a news! I'm happy to be updated on this. In the "JAMES 2.4 Road
Map" thread you and Vincenzo wrote that handler api changes would have
been part of the minor release you were proposing (with commons-daemon
and few other features).
I would like to see less discussions like this one and more pratical
discussions on code/issues to be included in each release, commitment
and collaboration.
>> I will be really happy if you do [the handlerapi-v2], because it is
>> the bigger missing piece for next-major.
>
> That and the scheduler/spooler changes. I was going to work on the handler
> this week, but ended up fixing the other two bugs instead. But as soon as I
> finish packing and invoicing, back to the handler API. :-)
Are scheduler/spooler changes you planned "config.xml compatible"?
I remember your "starting" proposal and it was not compatible. If you
can do it compatible it would be a great feature!
>> I think timeframe is a key part of the next-major release, and we'll
>> probably postpone some of the feature expected to be in next-major
>> if they are not ready for the estimated branch time.
>
> It is not a matter of features. If you really want to have a stable release
> anytime in early 2007, we're going to have to get serious, compare v2.3.0
> with trunk, branch trunk with largely the same code that is in v2.3.0 except
> for known and reviewed improvements, and go from there. Some of us are
> going to have to review changes --- line for line --- between the stable
> code and whatever we copy from trunk. Until then, I'm just going to view
> trunk as an unstable dumping ground.
Well, you're free to have your own view on what is stable and what is
not, and how much time is going to take to consolidate some code, and I
can't try to convince you, but you have to understand that your view
could also be wrong.
I and Norman already do this review work day by day, and I guess we have
more eyes on trunk now than we had in the last year on the 2.3 branch.
I feel current trunk is much more stable than trunk when we branched
2.3. Even more, I feel it is more stable that 2.3.0b1.
The most important fact is that a lot of code changed, but we had no
critical changes on the core, that we instead had in 2.3.0 (mimemessage
copyonwrite proxy, repository locks management and similar).
>> "next-major" had a lot of supporter in the vote I discussed above, so I
>> expect a lot of effort to make that real in the estimated timeframe.
>
> Actually, no. What people said was that they figured that you'd be doing
> it. Re-read the e-mails.
Sorry but I read it again 5 times, in the vote I started I never wrote I
would have done something. If you can correct my english interpretation
please help me, because I tried to be as clear as possible.
> For example, I would not expect to see the refactored Mailet API in a
> production release anytime soon.
>
> --- Noel
Nor do I. And they are not in trunk. And I would currently veto the
inclusion in trunk. And I understood from Danny that his work is an
experiment to have a strawman implementation to better discuss the next
mailet apis (I asked Danny which version he's targetting but he never
replied, but I guess he target next-greater and not next-major).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next 2.x release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Well, I believe in you, but I also know that you are the only supporter
> of the "next-minor"
Actually not, but I believe that you've talked most people to death on it.
That doesn't work on me.
> and you are so busy that you have to vote on the "James Server future
> releases/road maps" vote I started in October the 25th.
Actually, I just prioritize my time. First, I was at a conference, and then
I was fixing fictional bugs because my production server shared my
delusions.
> So I think it is safer for the project if we keep open the way to
> a 2.3.1 in case you'll be busier than you think now and we have to
> cancel next-minor.
My time to waste.
> The doubts you later expose about "next-major" are the same doubts I
> have about your next-minor: I understood you want handlerapi-v2 in
> "next-minor"
In the first out? I doubt it. Ever? That would all depend on just how bad
the code is that comes over from trunk.
> I will be really happy if you do [the handlerapi-v2], because it is
> the bigger missing piece for next-major.
That and the scheduler/spooler changes. I was going to work on the handler
this week, but ended up fixing the other two bugs instead. But as soon as I
finish packing and invoicing, back to the handler API. :-)
> I think timeframe is a key part of the next-major release, and we'll
> probably postpone some of the feature expected to be in next-major
> if they are not ready for the estimated branch time.
It is not a matter of features. If you really want to have a stable release
anytime in early 2007, we're going to have to get serious, compare v2.3.0
with trunk, branch trunk with largely the same code that is in v2.3.0 except
for known and reviewed improvements, and go from there. Some of us are
going to have to review changes --- line for line --- between the stable
code and whatever we copy from trunk. Until then, I'm just going to view
trunk as an unstable dumping ground.
> "next-major" had a lot of supporter in the vote I discussed above, so I
> expect a lot of effort to make that real in the estimated timeframe.
Actually, no. What people said was that they figured that you'd be doing
it. Re-read the e-mails.
For example, I would not expect to see the refactored Mailet API in a
production release anytime soon.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Danny Angus wrote:
>> Stefano Bagnara <ap...@bago.org> wrote:
>>> Sorry I don't understand this message. I understood we defined the
>>> following:
>>> 2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
>>> release something if needed (the unbounded cache and the connection
>>> accepting problem are good candidate to decide we need it).
>
> I doubt that we'll ever do this, since it would be subsumed by:
Well, I believe in you, but I also know that you are the only supporter
of the "next-minor" and you are so busy that you have to vote on the
"James Server future releases/road maps" vote I started in October the
25th. So I think it is safer for the project if we keep open the way to
a 2.3.1 in case you'll be busier than you think now and we have to
cancel next-minor.
>>> next-minor: the release you said you want to work and that will be based
>>> on 2.3 branch (but not the 2.3 branch itself) and you want to backport
>>> things from trunk (to be released in 1-2 months).
>
> which is what I'm working on. And of course it would be from the v2.3
> branch, which is why it still exists. So far the list includes:
>
> - removal of InetAddress cache
> - connection accepting fix
> - per IP connection enhancement
>
> The latter two are pending Norman's changes for the last, since those files
> are identical between v2.3 and trunk.
As you are the only active supporter of this next-minor release you're
almost free to do everything you want preparing the next-minor proposal,
but please work in the "next-minor" branch and not in the "v2.3" branch.
The doubts you later expose about "next-major" are the same doubts I
have about your next-minor: I understood you want handlerapi-v2 in
"next-minor" and it will be an hard task to complete that branch and
consolidate it to be released in a month or 2. Believe me: I will be
really happy if you do this, because it is the bigger missing piece for
next-major.
>>> next-major: the release we are currently preparing on trunk and that
>>> we'll branch soon (in 1-2 months).
>
> I doubt that timeframe, but timeframe is irrelevant.
>
> --- Noel
Well, I think timeframe is a key part of the next-major release, and
we'll probably postpone some of the feature expected to be in next-major
if they are not ready for the estimated branch time. This is my current
feeling about this issue, but we'll of course discuss together the issue
in the first weeks of december.
"next-major" had a lot of supporter in the vote I discussed above, so I
expect a lot of effort to make that real in the estimated timeframe.
That said, let's keep working, we all have a lot to do in our branches
:-) and it is really cool to see so much different authors in the commit
notifications!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next 2.x release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny Angus wrote:
> Standing up for Stefano here..
Nothing to stand up for ... it is just another instance of the silly
nomenclature problem.
> Stefano Bagnara <ap...@bago.org> wrote:
> > Sorry I don't understand this message. I understood we defined the
> > following:
>
> > 2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
> > release something if needed (the unbounded cache and the connection
> > accepting problem are good candidate to decide we need it).
I doubt that we'll ever do this, since it would be subsumed by:
> > next-minor: the release you said you want to work and that will be based
> > on 2.3 branch (but not the 2.3 branch itself) and you want to backport
> > things from trunk (to be released in 1-2 months).
which is what I'm working on. And of course it would be from the v2.3
branch, which is why it still exists. So far the list includes:
- removal of InetAddress cache
- connection accepting fix
- per IP connection enhancement
The latter two are pending Norman's changes for the last, since those files
are identical between v2.3 and trunk.
> > next-major: the release we are currently preparing on trunk and that
> > we'll branch soon (in 1-2 months).
I doubt that timeframe, but timeframe is irrelevant.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Danny Angus <da...@gmail.com>.
Guys,
Standing up for Stefano here..
On 11/4/06, Stefano Bagnara <ap...@bago.org> wrote:
> Sorry I don't understand this message. I understood we defined the
> following:
>
> 2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
> release something if needed (the unbounded cache and the connection
> accepting problem are good candidate to decide we need it).
>
> next-minor: the release you said you want to work and that will be based
> on 2.3 branch (but not the 2.3 branch itself) and you want to backport
> things from trunk (to be released in 1-2 months).
>
> next-major: the release we are currently preparing on trunk and that
> we'll branch soon (in 1-2 months).
This is (or should be) reflected in the STATUS file.
(yeah STATUS file!)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Danny Angus <da...@gmail.com>.
On 11/5/06, Noel J. Bergman <no...@devtech.com> wrote:
> This is just the silly nomenclature problem. Next Minor should be v2.4,
> since v2.3.x would be just a v2.3 bug fix. Next Major should be v3.0. But
> since we haven't agreed on the version names, we're constantly running afoul
> of them.
Right then.
*Please* create a proposal, and a vote thread for an approach to
naming/numbering and log them in the STATUS file.
Then (no matter *what* we decide) we can at least record what we
decided and stick to it.
This is too much of a Pain in the Arse to let it continue much longer.
How on earth can we be expected to plan anything properly if we can't
even agree how to refer to things when we discuss them.
:-)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Norman Maurer <nm...@byteaction.de>.
Hi all,
i fully agree with Stefano.. Thats the way we should follow
bye
Norman
Danny Angus schrieb:
> Guys,
>
> Standing up for Stefano here..
>
> On 11/4/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Sorry I don't understand this message. I understood we defined the
>> following:
>>
>> 2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
>> release something if needed (the unbounded cache and the connection
>> accepting problem are good candidate to decide we need it).
>>
>> next-minor: the release you said you want to work and that will be based
>> on 2.3 branch (but not the 2.3 branch itself) and you want to backport
>> things from trunk (to be released in 1-2 months).
>>
>> next-major: the release we are currently preparing on trunk and that
>> we'll branch soon (in 1-2 months).
>
> This is (or should be) reflected in the STATUS file.
> (yeah STATUS file!)
>
> d.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,454d2aaf53071233790016!
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> But this time the problem is not only nomenclature, it is that you mixed
>> 2.3.1 and next-minor. See bottom.
>
> I was using 2.3.1 as a placeholder for next minor. Needed to call it
> something in the properties file. Would have prefered to just call it 2.4.
I know. The property file is an issue for the current
next-minor/next-major schema.
If you ask me to number both next-minor and next-major now I would say:
2.4 for next-minor, 2.5 for next-major. Temporary numbers for the
property files. So we can keep using next-*. OK?
>> No, please! v2.3 branch is for 2.3.1 and we should backport there only
>> bugfixes. There is already need for the v2.3 branch to be separated by
>> the next-minor branch because the accept and unbounded cache fixes can
>> be included in v2.3 branch while the per service/per ip connection limit
>> can be only committed to the next-minor branch.
>
> If you think that I am going to maintain fixes in several separate branches,
> you are crazier than I am. :-)
Yeah, I'm crazier, for sure ;-) Was it a match?
I will help for 2.3.1 on the 2.3 branch and with next-major.
You can concentrate your efforts on next-minor so no "several separate
branches" for you.
> I'll be happy to rename the v2.3 branch to
> be the next minor branch, and copy the 2.3.0 tag back as the v2.3 branch for
> you to maintain if that's your wish, but I've already been there, done that,
> and have the T-shirt. Not going to happen again unless it has to happen,
> and it doesn't. Perhaps you'll just to have to learn the same lessons about
> release management that we learned the hard way.
I think we need both 2.3.1 (bugfixes only) and next-major.
I can be convinced that next-minor can replace 2.3.1, but you have to
give more details on next-minor, in the mean time leave the v2.3 branch
for 2.3.1 and create a new branch for next-minor.
> Me, I'm planning to maintain a stable release branch and work on new things
> in trunk.
"maintain a stable release branch" means "next-minor" ?
if this is true, and you can limit your trunk work to config.xml and
storage backward compatible changes until we'll branch next-major then
everything is ok, otherwise let's discuss a solution.
>> Maybe we decide not to release 2.3.1 and simply release "next-minor" as
>> 2.4.0
>
> That'd be my best guess.
Maybe.
We'll know this when you'll give us more details (I mean specific list
of features, and confirm the dates that are on the STATUS file) on
next-minor and 2.3.1 is the insurance in the mean time.
>> or maybe we decide to release a 2.3.1 in a month and release "next-major"
>> later if we decide not to release "next-minor".
>
> I highly doubt it. Not unless "next-major" comes from the v2.3.0 codebase,
> or a seriously stripped and vetted trunk.
>
> --- Noel
*We* *are* *serious*, and we already vetted trunk in the last year: you
can doubt the fact that we are serious but this won't make us jokers.
Maybe you're simply fearing what you don't know: this often happens to
humans :-) .
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next 2.x release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> But this time the problem is not only nomenclature, it is that you mixed
> 2.3.1 and next-minor. See bottom.
I was using 2.3.1 as a placeholder for next minor. Needed to call it
something in the properties file. Would have prefered to just call it 2.4.
> No, please! v2.3 branch is for 2.3.1 and we should backport there only
> bugfixes. There is already need for the v2.3 branch to be separated by
> the next-minor branch because the accept and unbounded cache fixes can
> be included in v2.3 branch while the per service/per ip connection limit
> can be only committed to the next-minor branch.
If you think that I am going to maintain fixes in several separate branches,
you are crazier than I am. :-) I'll be happy to rename the v2.3 branch to
be the next minor branch, and copy the 2.3.0 tag back as the v2.3 branch for
you to maintain if that's your wish, but I've already been there, done that,
and have the T-shirt. Not going to happen again unless it has to happen,
and it doesn't. Perhaps you'll just to have to learn the same lessons about
release management that we learned the hard way.
Me, I'm planning to maintain a stable release branch and work on new things
in trunk.
> Maybe we decide not to release 2.3.1 and simply release "next-minor" as
> 2.4.0
That'd be my best guess.
> or maybe we decide to release a 2.3.1 in a month and release "next-major"
> later if we decide not to release "next-minor".
I highly doubt it. Not unless "next-major" comes from the v2.3.0 codebase,
or a seriously stripped and vetted trunk.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>> I simply said that I think [that] this is a new feature/improvement and
>> can't be backported to 2.3 for the 2.3.1 release. If, instead, you was
>> already talking about "next-minor" then I agree you can backport it
>
> +1
Ok.
> This is just the silly nomenclature problem. Next Minor should be v2.4,
> since v2.3.x would be just a v2.3 bug fix. Next Major should be v3.0. But
> since we haven't agreed on the version names, we're constantly running afoul
> of them.
Yes, nomenclature problem: "should" is not "will be".
Imho next-major could even be 2.4 or 2.5 ;-) and we really can't know
this until we'll branch, discuss, vote for it.
But this time the problem is not only nomenclature, it is that you mixed
2.3.1 and next-minor. See bottom...
>> please create a next-minor branch starting from the v2.3 branch
>> and backport the code there and not on the 2.3 branch.
>
> The v2.3 branch *is* the next minor branch. We have no need for another.
> If, for some reason, we need just a bug fix branch, we can copy from the tag
> for 2.3.0. I can rename the branch if it makes you happier. I had planned
> to do that earlier, but we can't agree on the names.
>
> --- Noel
No, please! v2.3 branch is for 2.3.1 and we should backport there only
bugfixes. There is already need for the v2.3 branch to be separated by
the next-minor branch because the accept and unbounded cache fixes can
be included in v2.3 branch while the per service/per ip connection limit
can be only committed to the next-minor branch.
If you started working on next-minor please create a next-minor branch
and work there. next-minor is not v2.3, is simply a new branch based on
what we have in v2.3.
So don't rename the branch. v2.3 is there because we already have
backported bugs and we may want to release a 2.3.1 from there. If you're
ready to work on next-minor create a new branch and work there. This is
what we agreed.
simply use "next-minor" as the branch name: there is no need to have an
agreement on version when we already had at least an agreement on the label.
Maybe we decide not to release 2.3.1 and simply release "next-minor" as
2.4.0, or maybe we decide to release a 2.3.1 in a month and release
"next-major" later if we decide not to release "next-minor". We can't
make many plans on next-minor because you are the only one that wanted
to work on it, and you never wrote what exactly you intend to backport
from trunk to next-minor. I think that no one but you have understood
what you're planning for next-minor ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Next 2.x release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> You was referring to the "per service / per ip connection limit" feature
> that maybe we'll implement on trunk (it is not there yet).
Right. It is just a configuration enhancement to the code already present
in trunk, and easily backported to v2.3. I've already backported the
current code in my private build for the 2.3.0 successor, but am waiting for
Norman to do the additional enhancements to trunk before backporting them in
SVN, since we'd want the enhancement and are in no rush to release.
> I simply said that I think [that] this is a new feature/improvement and
> can't be backported to 2.3 for the 2.3.1 release. If, instead, you was
> already talking about "next-minor" then I agree you can backport it
+1
This is just the silly nomenclature problem. Next Minor should be v2.4,
since v2.3.x would be just a v2.3 bug fix. Next Major should be v3.0. But
since we haven't agreed on the version names, we're constantly running afoul
of them.
> please create a next-minor branch starting from the v2.3 branch
> and backport the code there and not on the 2.3 branch.
The v2.3 branch *is* the next minor branch. We have no need for another.
If, for some reason, we need just a bug fix branch, we can copy from the tag
for 2.3.0. I can rename the branch if it makes you happier. I had planned
to do that earlier, but we can't agree on the names.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Next 2.x release
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> The per IP connection limit change is a feature, I don't think we want
>> to backport it to the 2.3 branch (or at least I think we should not add
>> new features to the 2.3 branch).
>
> I'm sorry. Which part of trunk isn't trustworthy, we're going to do
> incremental releases based upon trustworthy code don't you understand?
>
> Having released v2.3.0, we ought to be able to have 2.4 (or 2.3.x) release
> in early December at the latest, so long as we stick with simple, safe,
> changes, which is all that are planned. The next thing coming from trunk is
> at least 6 months away.
>
> --- Noel
Sorry I don't understand this message. I understood we defined the
following:
2.3.1 - bug fix release: we simply fix bugs in v2.3 branch and will
release something if needed (the unbounded cache and the connection
accepting problem are good candidate to decide we need it).
next-minor: the release you said you want to work and that will be based
on 2.3 branch (but not the 2.3 branch itself) and you want to backport
things from trunk (to be released in 1-2 months).
next-major: the release we are currently preparing on trunk and that
we'll branch soon (in 1-2 months).
You was referring to the "per service / per ip connection limit" feature
that maybe we'll implement on trunk (it is not there yet). I simply said
that I think (and I think also others agreed on this) that this is a new
feature/improvement and can't be backported to 2.3 for the 2.3.1
release. If, instead, you was already talking about "next-minor" then I
agree you can backport it (and I'm happy you work on this), but please
create a next-minor branch starting from the v2.3 branch and backport
the code there and not on the 2.3 branch.
I thought this was what we all agreed, but I may have misunderstood
something, so please correct me if it happened.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Next 2.x release
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> The per IP connection limit change is a feature, I don't think we want
> to backport it to the 2.3 branch (or at least I think we should not add
> new features to the 2.3 branch).
I'm sorry. Which part of trunk isn't trustworthy, we're going to do
incremental releases based upon trustworthy code don't you understand?
Having released v2.3.0, we ought to be able to have 2.4 (or 2.3.x) release
in early December at the latest, so long as we stick with simple, safe,
changes, which is all that are planned. The next thing coming from trunk is
at least 6 months away.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Long-standing ServerConnection bug
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> I'll look into the change to use notification from the runners.
>
> Done. Currently testing with my private build of 2.3.1. Will apply to
> trunk. Am waiting for Norman to do the per IP changes before committing to
> that area of v2.3.
>
> --- Noel
The per IP connection limit change is a feature, I don't think we want
to backport it to the 2.3 branch (or at least I think we should not add
new features to the 2.3 branch).
The accept problem, instead, is a bug (minor), and I agree we can
backport it to the 2.3 branch.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'll look into the change to use notification from the runners.
Done. Currently testing with my private build of 2.3.1. Will apply to
trunk. Am waiting for Norman to do the per IP changes before committing to
that area of v2.3.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
Ok, the current code I'm testing is
while (maxOpenConn > 0 && clientConnectionRunners.size() >= maxOpenConn) {
getLogger().warn("Maximum number of open connections (" +
clientConnectionRunners.size() +
") reached - skipping accept().");
synchronized (this) { wait(1000); }
}
clientSocket = serverSocket.accept();
which seems to be a minimal change (the addition of the inner loop). I'll
look into the change to use notification from the runners.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
> if (maxOpen > 0 && clientConnectionRunners.zize() >= maxOpenConn)
Er, if (maxOpenConn > 0 && clientConnectionRunners.size() >= maxOpenConn)
Silly typos.
Instead of waiting for a period (whatever value), we could modify the client
runners to notify the accept thread when they are free, but first I want to
see the overall impact.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Long-standing ServerConnection bug
Posted by "Noel J. Bergman" <no...@devtech.com>.
In more detail, it appears that for each service there is a single
ServerConnection with one thread waiting on accept() in the run() method,
and then acquiring worker threads for each accept()ed cliented connection.
I'm going to try:
if (maxOpen > 0 && clientConnectionRunners.zize() >= maxOpenConn) {
wait(100);
} else {
clientSocket = serverSocket.accept();
}
And see if that resolves the issue.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org