Comment 1 Eike Stepper 2011-07-05 03:53:35 EDT

(In reply to comment #0)
> [...] This timeout is not configurable via the cdo-server.xml 

True.

> or otherwise.

Not true. All aspects are configurable programmatically, e.g.:

    IRepository repository = getRepository();
    repository.getSessionManager().addListener(new ContainerEventAdapter<ISession>()
    {
      @Override
      protected void onAdded(IContainer<ISession> container, ISession session)
      {
        ISessionProtocol protocol = session.getProtocol();
        if (protocol instanceof ISignalProtocol)
        {
          ISignalProtocol<?> signalProtocol = (ISignalProtocol<?>)protocol;
          signalProtocol.setTimeout(30L * 1000L);
        }
      }
    });

I wonder if the protocol read timeouts should always be the same on server side and client side...

Apart from this, can you please describe your underlying problem again? Was it about timeouts during long running commits?

Comment 2 Eike Stepper 2011-07-05 03:53:48 EDT

Committed revision 8591:
- trunk/plugins/org.eclipse.emf.cdo.tests

Comment 3 Eike Stepper 2011-07-05 03:53:58 EDT

Committed revision 8591

Comment 4 Eike Stepper 2011-07-05 04:20:21 EDT

Committed revision 8594:
- trunk/plugins/org.eclipse.emf.cdo.tests

Comment 5 Eike Stepper 2011-07-05 04:20:30 EDT

Committed revision 8594

Comment 6 Christophe Bouhier 2011-07-05 06:41:31 EDT

Hi Eike, 

We have this problem, when loading a lot of test data, which is committed in one go. 


(In reply to comment #5)
> Committed revision 8594

Comment 7 Eike Stepper 2011-07-05 06:52:11 EDT

I'll try to reproduce it in a test case...

Comment 8 Eike Stepper 2011-07-05 07:25:14 EDT

A question: when the (read) timeout happens on the server, is the network under heavy load? or the committing client und heavy processing load? The timeout basically means that the server was trying for more than 10 seconds to read a byte from the committing client. I would like to get an impression whether the actual timeout is a good signal that latency/error/heavy load is properly detetcted or if a timer reset is missing...

Comment 9 Christophe Bouhier 2011-07-05 07:54:45 EDT

There is no other activity on the server than, loading the data. No clients are connected except the test data loader. @Martin, do we have more details on this? 


(In reply to comment #8)
> A question: when the (read) timeout happens on the server, is the network under
> heavy load? or the committing client und heavy processing load? The timeout
> basically means that the server was trying for more than 10 seconds to read a
> byte from the committing client. I would like to get an impression whether the
> actual timeout is a good signal that latency/error/heavy load is properly
> detetcted or if a timer reset is missing...

Comment 10 Eike Stepper 2011-07-05 13:57:09 EDT

Committed revision 8604

I've added a test case that simulates a large commit (large as in "takes long to trasmit to server"): 

	org.eclipse.emf.cdo.tests.TransactionTest._testLongCommit2()
	
But I could solve the timeouts with:

  session.options().setCommitTimeout(60);

Comment 11 Martin Taal 2011-07-06 01:04:59 EDT

Hi Eike,
Thanks! This helped.

But in our case we had to cast to a different Options object:
  ((org.eclipse.emf.cdo.net4j.CDOSession.Options)cdoSession.options()).setCommitTimeout(60);

this because our session is  org.eclipse.emf.cdo.session.CDOSession which returns  a different options class from the options() method.

gr. Martin

Comment 12 Eike Stepper 2011-07-06 01:18:57 EDT

Committed revision 8607:
- trunk/plugins/org.eclipse.emf.cdo.tests

Comment 13 Eike Stepper 2011-07-06 01:22:19 EDT

(In reply to comment #11)
> Hi Eike,
> Thanks! This helped.
> 
> But in our case we had to cast to a different Options object:
>  
> ((org.eclipse.emf.cdo.net4j.CDOSession.Options)cdoSession.options()).setCommitTimeout(60);
> 
> this because our session is  org.eclipse.emf.cdo.session.CDOSession which
> returns  a different options class from the options() method.
> 
> gr. Martin

I'd prefer to cast the session already to org.eclipse.emf.cdo.net4j.CDOSession ;-)

Comment 14 Eike Stepper 2012-08-14 22:55:37 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 15 Eike Stepper 2013-06-27 04:06:09 EDT

Moving all outstanding enhancements to 4.3

Comment 16 Eike Stepper 2014-08-19 09:23:15 EDT

Moving all open enhancement requests to 4.4

Comment 17 Eike Stepper 2014-08-19 09:35:01 EDT

Moving all open enhancement requests to 4.4

Comment 18 Eike Stepper 2015-07-14 02:18:08 EDT

Moving all open bugzillas to 4.5.

Comment 19 Eike Stepper 2016-07-31 01:01:00 EDT

Moving all unaddressed bugzillas to 4.6.

Comment 20 Eike Stepper 2017-12-28 01:14:24 EST

Moving all open bugs to 4.7

Comment 21 Eike Stepper 2019-11-08 02:03:56 EST

Moving all unresolved issues to version 4.8-

Comment 22 Eike Stepper 2019-12-13 12:53:20 EST

Moving all unresolved issues to version 4.9

Comment 23 Eike Stepper 2020-12-11 10:43:39 EST

Moving to 4.13.