|
| Re: [CDO][0.8.0] Update [message #96379 is a reply to message #96361] |
Mon, 10 September 2007 08:23  |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Simon,
Comments inline...
Simon McDuff schrieb:
> Hi Eike,
>
> Here some update about our work.
>
> We are putting CDO/NEt4J 0.8.0 in Prod September 23.
>
> At some point, I will only integrated only bugs fixes in our systems to
> stabilize it and not integrating new problems.
>
> Each time we synchronize our code with the repository, we need to change few
> things to make it more stable... and more efficient.
>
> I think a few of these could be useful for the community and some not. Let
> me know if something interest you.
>
Yes, of course I'm interested in them ;-)
We should be able to integrate all good features and fixes into the code
base so that you don't have to maintain the changes locally.
> -Session.provideCOID
> return id immediately.. just slow down the system and takes too much
> memory for nothing.
>
I'd be more than happy if that effort would be for nothing (and could
thus be removed), but you know that you have a somewhat limited view of
things here because you are "only" using CDO native objects. With CDO
native objects you can't handle models that have not been generated for
CDO which includes the Ecore model itself or UML2. For these (legacy)
models it is unfortunately necessary to spend this effort. I've told you
that I can make it optional/configurable on a CDOSession base. But I
currently don't see a short way to completely remove this feature.
Maybe, when I have more time, I can investigate the use of dynamic
proxies at the client side to circumvent the pre-transmission of
concrete object types for list elements.
Added https://bugs.eclipse.org/bugs/show_bug.cgi?id=202768 so that we
don't forget aout it.
> -CDOViewImpl + CDORevisionResolverImpl
> Replace HashMap by JCSMap for cache. Didn`t find any elegant way to provide
> capability to the framework to put a Factory to create the cache....So I
> just replaced them manually.
>
If you open a feature request and attach your changes I can see if/how I
can make it configurable.
Please paste in URLs for any 3rd party code that I have to download.
> - SubClass CDOSessionImpl to provide functionnality like
>
> SyncRevisionRequest, SyncRevisionIndication - Not only CDO is used to
> access the database. The consequence is we do not have all the event.
> Actions :
> - Take the CDOID + version of every object in the CDOView
> - Send them to the server...
> - Server compare the version received from the client with the one in
> the database.
> - return CDORevisionIMpl of objects that have different version.
> - Client retrieved object and fire InvalidateEvent the Session... the
> session does the same things for all views.
> - Only the Session (even if we request the sync through the CDOView)
> that asked for the synchronisation will receive events. Other sessions
> connected to the server will not receive them.
>
Sounds good. I had something similar in mind to provide sort of
disconnected sessions.
Maybe I can add this feature (connect to repository, load graphs,
disconnect, work in disconnected session, reconnect and synchronize).
Please add a feature request and attach your changes/additions.
> -Query (OCL language) through JPA interface
> QueryRequest (Really basic)
> QueryIndication (Really basic)
>
> - Added IStoreIndex to query our database through JPA.
>
> - Added a JPA layer in front of CDO with basic implementation.(for now)
>
Even if it's basic at the moment we could make an optional separate
plugin out of it.
Please feel free to open a feature request and attach your initial
contribution.
> -Channel use SynchronousWorkSerializer instead of QueueWorkerWorkSerializer
> We still have some hanging.. but not sure what is the cause yet .... Before
> removing Session.provideCOID we had a lot of Out of memory.. and our server
> wasn`t stable. Some time we didn`t have any trace.... was just freezing.
> Lately we switch to SynchronousWorkSerializer to see if will happen again...
> I will let you know if it is still the problem.
>
SynchronousWorkSerializer isn't that ideal because in this particular
case it uses the thread of the TCPSelector.
Please reanimate https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366 if
you have still problems.
> With these changes and with the last version of CDODynamicFetchRuleAnalyzer
> (I will send it to you soon) I can go up to 12000 objects / sec.
>
Have already integrated your recent changes.
The numbers you give are really impressive!
Good work and thank you ;-)
Cheers
/Eike
|
|
|
| Re: [CDO][0.8.0] Update [message #609680 is a reply to message #96361] |
Mon, 10 September 2007 08:23 |
|
Hi Simon,
Comments inline...
Simon McDuff schrieb:
> Hi Eike,
>
> Here some update about our work.
>
> We are putting CDO/NEt4J 0.8.0 in Prod September 23.
>
> At some point, I will only integrated only bugs fixes in our systems to
> stabilize it and not integrating new problems.
>
> Each time we synchronize our code with the repository, we need to change few
> things to make it more stable... and more efficient.
>
> I think a few of these could be useful for the community and some not. Let
> me know if something interest you.
>
Yes, of course I'm interested in them ;-)
We should be able to integrate all good features and fixes into the code
base so that you don't have to maintain the changes locally.
> -Session.provideCOID
> return id immediately.. just slow down the system and takes too much
> memory for nothing.
>
I'd be more than happy if that effort would be for nothing (and could
thus be removed), but you know that you have a somewhat limited view of
things here because you are "only" using CDO native objects. With CDO
native objects you can't handle models that have not been generated for
CDO which includes the Ecore model itself or UML2. For these (legacy)
models it is unfortunately necessary to spend this effort. I've told you
that I can make it optional/configurable on a CDOSession base. But I
currently don't see a short way to completely remove this feature.
Maybe, when I have more time, I can investigate the use of dynamic
proxies at the client side to circumvent the pre-transmission of
concrete object types for list elements.
Added https://bugs.eclipse.org/bugs/show_bug.cgi?id=202768 so that we
don't forget aout it.
> -CDOViewImpl + CDORevisionResolverImpl
> Replace HashMap by JCSMap for cache. Didn`t find any elegant way to provide
> capability to the framework to put a Factory to create the cache....So I
> just replaced them manually.
>
If you open a feature request and attach your changes I can see if/how I
can make it configurable.
Please paste in URLs for any 3rd party code that I have to download.
> - SubClass CDOSessionImpl to provide functionnality like
>
> SyncRevisionRequest, SyncRevisionIndication - Not only CDO is used to
> access the database. The consequence is we do not have all the event.
> Actions :
> - Take the CDOID + version of every object in the CDOView
> - Send them to the server...
> - Server compare the version received from the client with the one in
> the database.
> - return CDORevisionIMpl of objects that have different version.
> - Client retrieved object and fire InvalidateEvent the Session... the
> session does the same things for all views.
> - Only the Session (even if we request the sync through the CDOView)
> that asked for the synchronisation will receive events. Other sessions
> connected to the server will not receive them.
>
Sounds good. I had something similar in mind to provide sort of
disconnected sessions.
Maybe I can add this feature (connect to repository, load graphs,
disconnect, work in disconnected session, reconnect and synchronize).
Please add a feature request and attach your changes/additions.
> -Query (OCL language) through JPA interface
> QueryRequest (Really basic)
> QueryIndication (Really basic)
>
> - Added IStoreIndex to query our database through JPA.
>
> - Added a JPA layer in front of CDO with basic implementation.(for now)
>
Even if it's basic at the moment we could make an optional separate
plugin out of it.
Please feel free to open a feature request and attach your initial
contribution.
> -Channel use SynchronousWorkSerializer instead of QueueWorkerWorkSerializer
> We still have some hanging.. but not sure what is the cause yet .... Before
> removing Session.provideCOID we had a lot of Out of memory.. and our server
> wasn`t stable. Some time we didn`t have any trace.... was just freezing.
> Lately we switch to SynchronousWorkSerializer to see if will happen again...
> I will let you know if it is still the problem.
>
SynchronousWorkSerializer isn't that ideal because in this particular
case it uses the thread of the TCPSelector.
Please reanimate https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366 if
you have still problems.
> With these changes and with the last version of CDODynamicFetchRuleAnalyzer
> (I will send it to you soon) I can go up to 12000 objects / sec.
>
Have already integrated your recent changes.
The numbers you give are really impressive!
Good work and thank you ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03605 seconds
] 
Search
Help
Register
Login
Home
