Comment 1 Eike Stepper 2010-10-26 01:29:16 EDT

Hi Erwin,

I noticed that the stack trace does not match the HEAD sources. Have you applied modifications or is it just not the hottest code?

If read (response) timeouts happen due to large data volumes being collected in the server, shouldn't you just increase the timeout value? You would do that in your CDOSessionConfigurationFactory where you'd create a CDOSessionConfiguration that sets the larger timeout value at the end of openSession like this:

((org.eclipse.emf.cdo.net4j.CDOSession)session).options().getProtocol().setTimeout(millis);

If you can confirm that this works for you I'd like to close this bug as WORKSFORME, but I'm waiting until you've tried it ;-)

Comment 2 Eike Stepper 2010-10-26 02:42:54 EDT

It seems that setting the protocol timeout for a Net4j CDOSession becomes easier with bug 278181:

    sessionsConfiguration.setSignalTimeout(millis);

Comment 3 Erwin Betschart 2010-10-27 05:00:49 EDT

(In reply to comment #1)

I'm working on HEAD but not latest.

I though about increasing the session timeout. This would fix the issue for some time depending how big the timeout is set.
The commit request (CommitTransactionRequest) is a RequestWithMonitoring which is (I think) the reason that the timeout of the session must not be increased when working with huge commits.
The ReplicateRepositoryRawRequest should also extend the RequestWithMonitoring because it will always be bigger that the biggest commit ever made.

Comment 4 Eike Stepper 2010-10-27 05:33:37 EDT

> The ReplicateRepositoryRawRequest should also extend the RequestWithMonitoring
> because it will always be bigger that the biggest commit ever made.

The idea is sound but looking at the code I have some doubts that it would reliably prevent the read timeout from happening on the client.

The CommitTransactionRequest is fundamentally different because it carries the major payload on the way *to* the repo, whereas the RepositoryReplicationRequest does it on the way *back*. From this point of view the active monitoring in the repo does not seem to replace the more general read timeouts but rather implement an *additional* mechanism.

Thinking...

Comment 5 Eike Stepper 2010-10-27 05:36:38 EDT

BTW. you can see the problem in RequestWithConfirmation:

  @Override
  void doExecute(BufferInputStream in, BufferOutputStream out) throws Exception
  {
    doOutput(out);
    doInput(in);
  }

A client that expects a confirmation starts immediately to read from the response stream after the last request byte has been sent. At that time also the protocol's read timeout starts to become effective.

Comment 6 Eike Stepper 2010-10-27 08:44:30 EDT

My last two comments turned out to be wrong: The RequestWithMonitoring mechanism *does* already reset the normal read timout ;-)

Comment 7 Erwin Betschart 2010-10-27 11:31:20 EDT

Created attachment 181846 [details]
patch

Implementation with monitoring.

Comment 8 Erwin Betschart 2010-10-28 11:26:47 EDT

Created attachment 181960 [details]
Patch

Previous fix didn't work.

-> Monitor is now started.
-> Breaks the progress monitor on client side.

Therefore not yet final fix.

Comment 9 Eike Stepper 2010-10-30 03:50:55 EDT

Created attachment 182096 [details]
Patch v3

I've consolidated the monitored signals in CDO.

Comment 10 Erwin Betschart 2010-11-03 07:03:16 EDT

(In reply to comment #9)
> Created an attachment (id=182096) [details]
> Patch v3
> 
> I've consolidated the monitored signals in CDO.

Tested your patch. Works well except the progress on the repository synchronizer 
is broken.

Always starts at 96%.

Comment 11 Erwin Betschart 2010-11-15 06:42:54 EST

Opened bug 330227 for the problem mentioned in comment 10.
Therefore this bug can be closed.

Comment 12 Eike Stepper 2010-11-15 10:27:26 EST

Thank you, Erwin!

Committed to HEAD

Comment 13 Eike Stepper 2011-06-23 03:42:15 EDT

Available in R20110608-1407