DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 14:50 ---
Here is what causes the problem:

in TcpReplicationThread line 142 the call to key.interestedOps blocks until the
select in the parallel execution of ReplicationListener returns the next time. 
I checked with adding debug output directly nefore and after.

Internet sources confirm, that register and setting interestedOps are blocking 
on select to the same selector.

Some people suggest putting wakeup directly before register and interstedOps, 
but since an interrupted select in ReplicationListener will very quickly do the 
next select, I think you need some way of informing ReplicationListener to not 
do the select until interestedOps has returned.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 14:55 ---
Why would you set tcpSelectorTimeout to 1000ms?

The tcpSelectorTimeout feature is in place because of a bug in java NIO. If 
your NIO is working bug free, then tcpSelectorTimeout should be 0, cause the 
selector should wake up by itself when it receives a package. In many Unix 
JDKs this is not the case, hence you can set it to 50ms.

I am setting this to INVALID, cause 1000ms in tcpSelectorTimeout is wrong. The 
problem is in Java NIO, not in Tomcat, hence you have to set 
tcpSelectorTimeout to a reasonable value. On windows you can set to 0, no 
timeout, cause on windows NIO works well, and the selector wakes up by itself 
when a data packet arrives


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 15:13 ---
I'm having a different opinion: it is well documented, that key.interestedOps() 
blocks waiting for select() to return - dependent on the JVM implementation. It 
is not a bug in the JVM!

You call interestedOps() in TcpReplicationThread line 142 although there is a 
parallelly executing select() call in ReplicationListener. So the interestedOps
() blocks the TcPReplicationThread until the select() in ReplicationListener 
returns. Since during that time OP_READ is not set, select might block a very 
long time.

Of course setting tcpSelectorTimeout to a very small value looks like a 
workaround. But still it is not a safe solution: depending on the scheduling of 
threads on CPUs it might happen, that ReplicationListener calls select() again, 
before interestedOps() is able to set the new flags.

I really think you need a design, 
- where you check for pending interestedOps or register calls before retrying 
select
- where you "register" interestedOps or register calls as pending, afterwards 
call wakeup, then do the interestedOps or register call and 
finally "unregister" the calls.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 15:36 ---
Reopened - reason see my 2 last comments. tcpSelectorTimeout was only chosen so 
big to demonstrate the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 16:13 ---
Yes, you are absolutely right, the interestOps in unix is blocking until 
select is done.

I will fix this, many thanks for the detailed bug report

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug





--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 18:09 ---
Thank you very much! I hope I don't bother you too much, but we plan to use TC
5.0 cluster in a high load mission critical application starting June. So we try
hard to help you improve robustness.

I think you do a wonderful job and we try to be as precise as possible with our
observations.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28259

Synchronous cluster very slow - select() bug

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-07 19:06 ---
As always, I stand corrected about interestOps blocking. This has been fixed,
however, setting tcpSelectorTimeout to 1000ms will still yield the same 
problems because of selector.select() will not wake up if new data comes in on 
the tcp channel.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 28259] - Synchronous cluster very slow - select() bug --> Ref #[1M5QNAEu7l48Bwe]

[webmail]

Dear [EMAIL PROTECTED],

Thank you for contacting the Juno Help Center.

Please note that this is an automated response and further replies to this mail will 
not be responded to.

Live technical support over e-mail is only available to Juno Platinum members writing 
through a Personal Assistance Ticket (PAT).

You are receiving this mail due to one of the following reasons:

[A]You're a Juno Platinum member and have NOT written to us from your Platinum 
account.

[B]You're replying to a mail received from our Customer Support technicians at 
[EMAIL PROTECTED], and have modified the original "Subject Line" of the mail.

[C]You're a Juno Free Internet service member.

*
[A]To give you the best service possible, we need some key information about your 
computer system and details of the problem & error messages received.

Visit our Web site at www.juno.com/techsupport/pat to create your own PAT and send a 
customized request to the Juno Customer Support Team.  You'll receive personalized 
assistance in approximately one business day.

Note:  This service is available for Platinum members only.

*
[B]If you've received a reply from [EMAIL PROTECTED] in response to a PAT created 
by you, please ensure that you reply to that mail for further assistance.

Note:  Remember to keep the "Subject Line" of the mail unchanged.  This will help us 
track your request, and serve you faster.

*
[C]If you are a Juno Free Internet service member and need technical support, 
please check out our other Support Options at 
http://www.juno.com/contact/free_index.html.

If you require assistance over e-mail, send a blank mail to [EMAIL PROTECTED] Our 
e-mail-based Automated response library will send you the solutions database and 
provide you with a means to retrieve a list of relevant support documents.

Thanks for using Juno!

Sincerely,

Juno Customer Care
http://help.juno.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]