Home » Modeling » EMF » [CDO] Profiling CDO
| [CDO] Profiling CDO [message #542542] |
Fri, 25 June 2010 09:46  |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Hi,
I'd like to know is there is some common knowledge with regard to CDO profiling.
More precisely, when retrieving models as local resources takes too much time, I need a methodology to identify any bottleneck.
This would help me in improving my metamodels and the way I use CDO.
regards,
Bastien
|
|
| | |
| Re: [CDO] Profiling CDO [message #542574 is a reply to message #542564] |
Fri, 25 June 2010 11:09  |
|
Am 25.06.2010 12:58, schrieb Bastien:
> We are indeed regularly encoutering performance issues while
> retrieving / committing models.
Can you describe the nature of these issues and give measures?
>
> We already significantly improved performances by applying some of the
> optimizations suggested on the page you are linking.
>
> At this stage, we feel that detecting the actual bottlenecks so that
> we could optimize in the proper way would be more efficient.
Hmm, something in this sentence seems to be missing. I feel that I need
it to understand it :P
> That would help us in asking more detailed questions ;)
>
> As an example, should properties of a reference in the metamodel be
> the cause of some slowness, how can we detect it?
Not that I know of. Nobody has reported performance issues for a long
while. That's why I'm walking in the dark without further infos/measures.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #543402 is a reply to message #542542] |
Tue, 29 June 2010 10:37 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Hi Eike,
My goal is to retrieve locally (as an XMI file) a resource from my CDO server,
I noticed that the method save(OutputStream outputStream, Map<?, ?> options) is not implemented for CDOResource.
Given that information, I chose to make a local copy of my resource with this kind of code :
localResource.getContents().addAll(EcoreUtil.copyAll(remoteR essource.getContents()));
and with that solution, I have checkout times between 150 and 8000 seconds for models between 2 and 15Mo (on a LAN, so I don't think it's a network issue).
that's why I'm wondering if i'm using the right retreival solution and if you have some advices to improve that.
Regards,
Bastien.
[Updated on: Tue, 29 June 2010 10:40] Report message to a moderator |
|
|
| Re: [CDO] Profiling CDO [message #543414 is a reply to message #543402] |
Tue, 29 June 2010 11:03 |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Bastien,
it is possible that lot of round-trip between client and server is
happening. In the worst case, if there is an content iterator, you'll
get round-trip per each EObject in the Resource tree. That could be a
lot of overhead, depending on the size of the model. As you may guess,
the bigger the model, the bigger the overhead.
Maybe you could perform prefetching of the resource before copying it.
This way you could mitigate a bit the roundtrip overhead, as prefetch
makes the client cache data with the minimum amount of client-server
round-trips.
org.eclipse.emf.cdo.CDOObject.cdoPrefetch(int)
This is available since 3.0.
Give it a try at least and let us know if you see any improvement.
Cheers,
Víctor.
Bastien escribió:
> Hi Eike,
>
> My goal is to retrieve locally (as an XMI file) a resource from my CDO
> server,
> I noticed that the method save(OutputStream outputStream, Map<?, ?>
> options) is not implemented for CDOResource.
> Given that information, I chose to make a local copy of my resource with
> this kind of code :
>
> localResource.getContents().addAll(EcoreUtil.copyAll(remoteR
> essource.getContents()));
>
> and with that solution, I have checkout times between 150 and 8000
> seconds for models between 2 and 15mo (on a LAN, so I don't think it's a
> network issue).
> that's why I'm wondering if i'm using the right retreival solution and
> if you have some advices to improve that.
>
> Regards,
> Bastien.
>
|
|
|
| Re: [CDO] Profiling CDO [message #543428 is a reply to message #542542] |
Tue, 29 June 2010 12:34 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Hi Victor,
I tried your solution, unfortunately it doesn't seems to change anything.
I added timers in order to have measurements :
for now I have something like this :
remoteResource.cdoPrefetch(CDORevision.DEPTH_INFINITE)
I also tried with a custom depth and no changes either
localResource.getContents().addAll(remoteRessource.getConten ts());
localResource.save(null);
Prefetching time: 391ms
Copying time: 564048ms
Saving time: 344ms
the model is about 3.5Mo (as an XMI file) and I'm on a 100Mb lan.
Regards,
Bastien.
Edit : following Cyril's post, I didn't use EcoreUtil#copy during these tests.
[Updated on: Tue, 29 June 2010 14:46] Report message to a moderator |
|
| | |
| Re: [CDO] Profiling CDO [message #543493 is a reply to message #543414] |
Tue, 29 June 2010 15:02 |
|
This is a multi-part message in MIME format.
--------------040709020302070307090500
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Guys,
I vaguely remember that there is a precondition for the prefetching to work effectively: The CDORevision of the CDOObject that you call cdoPrefetch() on must not already be on the client. If it is, then there will be no server round-trip triggered by the prefetch. If you can confirm this by ensuring that the resource that you call cdoPrefetch() on has never been loaded on that client and seeing that the load time decreases drastically, then we may want to consider to remove this constraint somehow.
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 29.06.2010 13:03, schrieb Víctor Roldán Betancort:
> Hi Bastien,
>
> it is possible that lot of round-trip between client and server is happening. In the worst case, if there is an content iterator, you'll get round-trip per each EObject in the Resource tree. That could be a lot of overhead, depending on the size of the model. As you may guess, the bigger the model, the bigger the overhead.
>
> Maybe you could perform prefetching of the resource before copying it. This way you could mitigate a bit the roundtrip overhead, as prefetch makes the client cache data with the minimum amount of client-server round-trips.
>
> org.eclipse.emf.cdo.CDOObject.cdoPrefetch(int)
>
> This is available since 3.0.
>
> Give it a try at least and let us know if you see any improvement.
>
> Cheers,
> Víctor.
>
> Bastien escribió:
>> Hi Eike,
>>
>> My goal is to retrieve locally (as an XMI file) a resource from my CDO server,
>> I noticed that the method save(OutputStream outputStream, Map<?, ?> options) is not implemented for CDOResource.
>> Given that information, I chose to make a local copy of my resource with this kind of code :
>>
>> localResource.getContents().addAll(EcoreUtil.copyAll(remoteR essource.getContents()));
>>
>> and with that solution, I have checkout times between 150 and 8000 seconds for models between 2 and 15mo (on a LAN, so I don't think it's a network issue).
>> that's why I'm wondering if i'm using the right retreival solution and if you have some advices to improve that.
>>
>> Regards,
>> Bastien.
>>
--------------040709020302070307090500
Content-Type: multipart/related;
boundary="------------080103070703040700030801"
--------------080103070703040700030801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Guys,<br>
<br>
I vaguely remember that there is a precondition for the prefetching
to work effectively: The CDORevision of the CDOObject that you call
cdoPrefetch() on must not already be on the client. If it is, then
there will be no server round-trip triggered by the prefetch. If you
can confirm this by ensuring that the resource that you call
cdoPrefetch() on has never been loaded on that client and seeing
that the load time decreases drastically, then we may want to
consider to remove this constraint somehow.<br>
<br>
<!--WISESTAMP_SIG_66763_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.04060109.08090001@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.04050703.09010806@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.06070402.00090904@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.04030201.09050806@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_66763_END--><br>
<br>
Am 29.06.2010 13:03, schrieb Víctor Roldán Betancort:
<blockquote cite="mid:i0ck4l$u0a$1@build.eclipse.org" type="cite">Hi
Bastien,
<br>
<br>
it is possible that lot of round-trip between client and server is
happening. In the worst case, if there is an content iterator,
you'll get round-trip per each EObject in the Resource tree. That
could be a lot of overhead, depending on the size of the model. As
you may guess, the bigger the model, the bigger the overhead.
<br>
<br>
Maybe you could perform prefetching of the resource before copying
it. This way you could mitigate a bit the roundtrip overhead, as
prefetch makes the client cache data with the minimum amount of
client-server round-trips.
<br>
<br>
org.eclipse.emf.cdo.CDOObject.cdoPrefetch(int)
<br>
<br>
This is available since 3.0.
<br>
<br>
Give it a try at least and let us know if you see any improvement.
<br>
<br>
Cheers,
<br>
Víctor.
<br>
<br>
Bastien escribió:
<br>
<blockquote type="cite">Hi Eike,
<br>
<br>
My goal is to retrieve locally (as an XMI file) a resource from
my CDO server,
<br>
I noticed that the method save(OutputStream outputStream,
Map<?, ?> options) is not implemented for CDOResource.
<br>
Given that information, I chose to make a local copy of my
resource with this kind of code :
<br>
<br>
localResource.getContents().addAll(EcoreUtil.copyAll(remoteR
essource.getContents()));
<br>
<br>
and with that solution, I have checkout times between 150 and
8000 seconds for models between 2 and 15mo (on a LAN, so I don't
think it's a network issue).
<br>
that's why I'm wondering if i'm using the right retreival
solution and if you have some advices to improve that.
<br>
<br>
Regards,
<br>
Bastien.
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>
--------------080103070703040700030801
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.04060109.08090001@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------080103070703040700030801
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.04050703.09010806@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------080103070703040700030801
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.06070402.00090904@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------080103070703040700030801
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.04030201.09050806@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------080103070703040700030801--
--------------040709020302070307090500--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #543494 is a reply to message #543449] |
Tue, 29 June 2010 15:04 |
|
This is a multi-part message in MIME format.
--------------020800090207020402080904
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
Please also note the other hints on http://wiki.eclipse.org/Tweaking_CDO_Performance .
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 29.06.2010 15:26, schrieb Bastien:
> Hi Cyril,
>
> I tryed to do so except that I don't rollback the transaction, I just don't commit it so no changes are done on my remote resource and my local one is succesfully copied.
>
> I didn't use EcoreUtil#copy in the measurements I gave earlier, I'll modify my previous post consequently.
>
> Regards,
> Bastien.
--------------020800090207020402080904
Content-Type: multipart/related;
boundary="------------050203070905040404050905"
--------------050203070905040404050905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Bastien,<br>
<br>
Please also note the other hints on
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Tweaking_CDO_Performance">http://wiki.eclipse.org/Tweaking_CDO_Performance</a> .
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<br>
<br>
<!--WISESTAMP_SIG_23141_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.03020304.01080806@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.09060002.03050309@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.06080808.04090909@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.04020808.09050204@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_23141_END--><br>
<br>
Am 29.06.2010 15:26, schrieb Bastien:
<blockquote cite="mid:i0cs9p$ie2$1@build.eclipse.org" type="cite">Hi
Cyril,
<br>
<br>
I tryed to do so except that I don't rollback the transaction, I
just don't commit it so no changes are done on my remote resource
and my local one is succesfully copied.
<br>
<br>
I didn't use EcoreUtil#copy in the measurements I gave earlier,
I'll modify my previous post consequently.
<br>
<br>
Regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------050203070905040404050905
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.03020304.01080806@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------050203070905040404050905
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.09060002.03050309@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------050203070905040404050905
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.06080808.04090909@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------050203070905040404050905
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.04020808.09050204@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------050203070905040404050905--
--------------020800090207020402080904--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #543843 is a reply to message #543745] |
Wed, 30 June 2010 17:37 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Bastien,
some tips to help finding out the bottleneck:
- Although you already tried out with prefetch, lets try at least if
increasing CDORevisionPrefetchingPolicy and CDOCollectionLoadingPolicy
has any impact. If you have large collections, you trying out with
chunkSizes of 100 and up...
- Try to use a profiler, like VisualVM (free), Yourkit Java Profiler
(comercial). These would help you find out which methods are taking most
CPU time.
- Not sure which Database you're using, but I would recommend trying H2.
Derby is definitely not recommended, it provides very poor performances
:( Try also HSQLDB, just so you can get some numbers as reference for
your measures / comparisons.
Let's us know it there is an improvement...
Bastien escribió:
> Hi Eike,
> I wrote the smallest program which retreives a model from my CDO, I
> applied the tweaks you describe here :
>
> http://wiki.eclipse.org/Tweaking_CDO_Performance
> Setting EMF Parameters
>
> Loading Partial Collections CDOCollectionLoadingPolicy chunksize = 100
>
> Prefetching Target Objects CDORevisionPrefetchingPolicy
> initialChunkSize = 10, resolveChunkSize = 20
>
> cdo-server.xml caching options
> <property name="currentLRUCapacity" value="100000"/>
> <property name="revisedLRUCapacity" value="100"/>
>
> I also prefetched my remote resource but it doesn't seems to be working
> properly in spite of your advice.
>
> I ran this program 5 times in a new workspace and from a newly started
> server.
> Here are the informations about the model I retreive:
> size: about 3.5Mo
> number of model elements : 59258
>
> copying times :
> #1: 133sec
> #2: 134sec
> #3: 129sec
> #4: 128sec
> #5: 126sec
>
> As I started from a clean workspace and a newly started server, when I
> made these retreivals I was sure that my CDO resource wasn't loaded
> client side.
>
> Regards,
> Bastien.
>
>
>
>
|
|
|
| Re: [CDO] Profiling CDO [message #544063 is a reply to message #543843] |
Thu, 01 July 2010 13:45 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Victor,
Thanks for the tips.
I first tried the alternative database servers you suggested. They were easy to set up, but timings were similar to what we already recorded with MySQL.
I then took a set of measures using a TCP proxy (from grinder.sourceforge.net), restarting the client and server between each test.
For all tests, I used the same 3Mo model (when serialized to XMI) composed of about 49000 EObjects.
For each measure, I modified createRevisionPrefetchingPolicy, initialChunkSize, numberOfIndexToResolve or cdoPrefetch, one at a time, up to large values (1000 or more).
No tweaking led to meaningful timing differences. According to logged traffic, I never got under 33000 client requests (the typical initial number of requests was 37000).
My feeling is that this high requests count is my current bottleneck. I also think that those CDO parameters only influence the fetching of direct children of each node.
Yet, interestingly, my test model is a rather shallow and wide tree (no references between siblings as an example). My understanding is that if only direct children are fetched, this graph structure will always lead to a high request count.
So I suppose that I need a "deep" fetching of children, greatchildren, etc. In this regard, what I feel is more surprising is that the cdoPrefetch parameter does not seem to influence this behavior; even set to 10 (our max tree depth is 7) or DEPTH_INFINITE, a large number of client requests is still performed.
Regards,
Bastien.
|
|
|
| Re: [CDO] Profiling CDO [message #544073 is a reply to message #544063] |
Thu, 01 July 2010 14:08 |
|
This is a multi-part message in MIME format.
--------------050806040305090305020806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Guys,
Unfortunately I do not have much time because I am with a customer until tomorrow. Have you already tried the mapping strategy HorizontalAuditMappingStrategyWithRanges? It has been contributed to optimize the many-valued feature mapping performance problems. Please try to find out how to set it up and come back with questions here ;-)
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 01.07.2010 15:45, schrieb Bastien:
> Victor,
>
> Thanks for the tips.
>
> I first tried the alternative database servers you suggested. They were easy to set up, but timings were similar to what we already recorded with MySQL.
>
>
> I then took a set of measures using a TCP proxy (from grinder.sourceforge.net), restarting the client and server between each test.
>
> For all tests, I used the same 3Mo model (when serialized to XMI) composed of about 49000 EObjects.
>
> For each measure, I modified createRevisionPrefetchingPolicy, initialChunkSize, numberOfIndexToResolve or cdoPrefetch, one at a time, up to large values (1000 or more).
>
> No tweaking led to meaningful timing differences. According to logged traffic, I never got under 33000 client requests (the typical initial number of requests was 37000).
>
>
> My feeling is that this high requests count is my current bottleneck. I also think that those CDO parameters only influence the fetching of direct children of each node.
>
> Yet, interestingly, my test model is a rather shallow and wide tree (no references between siblings as an example). My understanding is that if only direct children are fetched, this graph structure will always lead to a high request count.
>
> So I suppose that I need a "deep" fetching of children, greatchildren, etc. In this regard, what I feel is more surprising is that the cdoPrefetch parameter does not seem to influence this behavior; even set to 10 (our max tree depth is 7) or DEPTH_INFINITE, a large number of client requests is still performed.
>
>
> Regards,
> Bastien.
--------------050806040305090305020806
Content-Type: multipart/related;
boundary="------------080708080505010106000505"
--------------080708080505010106000505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Guys,<br>
<br>
Unfortunately I do not have much time because I am with a customer
until tomorrow. Have you already tried the
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
mapping strategy HorizontalAuditMappingStrategyWithRanges? It has
been contributed to optimize the many-valued feature mapping
performance problems. Please try to find out how to set it up and
come back with questions here ;-)<br>
<br>
<!--WISESTAMP_SIG_53373_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.06000808.07070208@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.09070602.06010308@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.01050500.04030808@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.07030904.09060100@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_53373_END--><br>
<br>
Am 01.07.2010 15:45, schrieb Bastien:
<blockquote cite="mid:i0i65f$2gc$1@build.eclipse.org" type="cite">Victor,
<br>
<br>
Thanks for the tips.
<br>
<br>
I first tried the alternative database servers you suggested. They
were easy to set up, but timings were similar to what we already
recorded with MySQL.
<br>
<br>
<br>
I then took a set of measures using a TCP proxy (from
grinder.sourceforge.net), restarting the client and server between
each test.
<br>
<br>
For all tests, I used the same 3Mo model (when serialized to XMI)
composed of about 49000 EObjects.
<br>
<br>
For each measure, I modified createRevisionPrefetchingPolicy,
initialChunkSize, numberOfIndexToResolve or cdoPrefetch, one at a
time, up to large values (1000 or more).
<br>
<br>
No tweaking led to meaningful timing differences. According to
logged traffic, I never got under 33000 client requests (the
typical initial number of requests was 37000).
<br>
<br>
<br>
My feeling is that this high requests count is my current
bottleneck. I also think that those CDO parameters only influence
the fetching of direct children of each node.
<br>
<br>
Yet, interestingly, my test model is a rather shallow and wide
tree (no references between siblings as an example). My
understanding is that if only direct children are fetched, this
graph structure will always lead to a high request count.
<br>
<br>
So I suppose that I need a "deep" fetching of children,
greatchildren, etc. In this regard, what I feel is more surprising
is that the cdoPrefetch parameter does not seem to influence this
behavior; even set to 10 (our max tree depth is 7) or
DEPTH_INFINITE, a large number of client requests is still
performed.
<br>
<br>
<br>
Regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------080708080505010106000505
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.06000808.07070208@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------080708080505010106000505
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.09070602.06010308@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------080708080505010106000505
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.01050500.04030808@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------080708080505010106000505
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.07030904.09060100@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------080708080505010106000505--
--------------050806040305090305020806--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #544117 is a reply to message #544100] |
Thu, 01 July 2010 15:27 |
|
This is a multi-part message in MIME format.
--------------060105020508060303090701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
Sorry, IIRC the HorizontalAuditMappingStrategyWithRanges was meant to optimize commits of changes ;-(
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 01.07.2010 17:09, schrieb Bastien:
> Hi Eike,
>
> I tried your solution, following this entry :
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=296440
>
> Unfortunately, I didn't notice any performance improvement.
> The retreival duration and the number of client requests are still the same as before.
>
> Regards,
> Bastien
--------------060105020508060303090701
Content-Type: multipart/related;
boundary="------------010008080501050703010402"
--------------010008080501050703010402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
Sorry, IIRC the HorizontalAuditMappingStrategyWithRanges was meant
to optimize commits of changes ;-(<br>
<br>
<!--WISESTAMP_SIG_58438_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.03060403.03050306@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.03000508.08020809@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.09050806.09060704@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.03080402.03070403@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_58438_END--><br>
<br>
Am 01.07.2010 17:09, schrieb Bastien:
<blockquote cite="mid:i0ib3f$6hc$1@build.eclipse.org" type="cite">Hi
Eike,
<br>
<br>
I tried your solution, following this entry :
<br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=296440">https://bugs.eclipse.org/bugs/show_bug.cgi?id=296440</a>
<br>
<br>
Unfortunately, I didn't notice any performance improvement.
<br>
The retreival duration and the number of client requests are still
the same as before.
<br>
<br>
Regards,
<br>
Bastien
<br>
</blockquote>
</body>
</html>
--------------010008080501050703010402
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.03060403.03050306@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------010008080501050703010402
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.03000508.08020809@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------010008080501050703010402
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.09050806.09060704@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------010008080501050703010402
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.03080402.03070403@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------010008080501050703010402--
--------------060105020508060303090701--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #544695 is a reply to message #544680] |
Mon, 05 July 2010 09:34 |
|
This is a multi-part message in MIME format.
--------------080900010504060108070205
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
As long as the cdoPrefetch() call is ignored for already loaded objects it may be a bad idea to use a RevisionPrefetchingPolicy with the CDOView. Maybe it helps to remove the policy and call cdoPrefetch() not on the resource but on its root objects?
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 05.07.2010 11:13, schrieb Bastien:
> Hi Eike,
>
> following what you said about cdoPrefetch() method which was that it only works when it's the first time the resource is loaded, I studied a bit how this works and I think the way I get a resource from my CDO is not right.
>
> Here's how I do this :
>
> CDOView view = session.openView();
> view.options().setRevisionPrefetchingPolicy(CDOUtil.createRe visionPrefetchingPolicy(10000));
>
> cdoResource = (CDOResource) view.getResource("/pathToMyResource");
> cdoResource.cdoPrefetch(10);
>
> The thing is, the getResource() method automatically loads it with default prefetching depth value : 0.
> So when I call the cdoPrefetch() method, it considers that my resource is already loaded and doesn't process the prefetching code.
>
> that's why I'd like to know either if there's a way to set a default prefetching parameter (server side for example) or if I my code have to be modified.
>
> regards,
> Bastien.
--------------080900010504060108070205
Content-Type: multipart/related;
boundary="------------090804070407040006000405"
--------------090804070407040006000405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Bastien,<br>
<br>
As long as the cdoPrefetch() call is ignored for already loaded
objects it may be a bad idea to use a RevisionPrefetchingPolicy with
the CDOView. Maybe it helps to remove the policy and call
cdoPrefetch() not on the resource but on its root objects?<br>
<br>
<!--WISESTAMP_SIG_21975_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.00020109.04020306@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.05050103.05050407@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.00030005.01020709@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.02070303.05070102@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_21975_END--><br>
<br>
Am 05.07.2010 11:13, schrieb Bastien:
<blockquote cite="mid:i0s7on$98h$1@build.eclipse.org" type="cite">Hi
Eike,
<br>
<br>
following what you said about cdoPrefetch() method which was that
it only works when it's the first time the resource is loaded, I
studied a bit how this works and I think the way I get a resource
from my CDO is not right.
<br>
<br>
Here's how I do this :
<br>
<br>
CDOView view = session.openView();
<br>
view.options().setRevisionPrefetchingPolicy(CDOUtil.createRe
visionPrefetchingPolicy(10000));
<br>
<br>
cdoResource = (CDOResource) view.getResource("/pathToMyResource");
<br>
cdoResource.cdoPrefetch(10);
<br>
<br>
The thing is, the getResource() method automatically loads it with
default prefetching depth value : 0.
<br>
So when I call the cdoPrefetch() method, it considers that my
resource is already loaded and doesn't process the prefetching
code.
<br>
<br>
that's why I'd like to know either if there's a way to set a
default prefetching parameter (server side for example) or if I my
code have to be modified.
<br>
<br>
regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------090804070407040006000405
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.00020109.04020306@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------090804070407040006000405
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.05050103.05050407@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------090804070407040006000405
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.00030005.01020709@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------090804070407040006000405
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.02070303.05070102@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------090804070407040006000405--
--------------080900010504060108070205--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #544803 is a reply to message #544756] |
Mon, 05 July 2010 14:17 |
|
Am 05.07.2010 14:42, schrieb Bastien:
> Hi Eike,
>
> Here's how my code looks like considering the advices you gave me:
>
> cdoResource = view.getResource("/pathToMyResource");
>
> EObject rootObj = cdoResource.getContents().get(0);
>
> ((CDOObject)rootObj).cdoPrefetch(10);
> my root object is automatically added to the revisionCache when accessed with cdoResource.getContents().get(0);
As I mentioned before, this must be a result of your view.options().setRevisionPrefetchingPolicy(...). Remove it if you want to manually prefetch trees.
>
> My feeling is that during the prefetching, the revisionManager considers it as available (RevisionInfo.Available) instead of missing (RevisionInfo.Missing), and that's why the prefetching is not done.
Exactly. I mentioned before that you could submit a bugzilla to ask for a change.
>
> That's why I'm wondering if there's a problem with my code or if maybe there's a way to clean up the revision cache.
Without the RevisionPrefetchingPolicy your root objects should be in PROXY state and their revisions should not be already cached.
>
> Regards,
> Bastien.
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #544876 is a reply to message #544838] |
Mon, 05 July 2010 19:49 |
|
This is a multi-part message in MIME format.
--------------010000000106060405010806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
Are you using the new legacy mode? Maybe by accident?
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 05.07.2010 18:46, schrieb Bastien:
> Eike,
>
> I already removed the view.options().setRevisionPrefetchingPolicy(...) in my previous post,I should have said so in order to be clearer, my apologies.
>
> When the cdoPrefetch() method is called my root object is in CLEAN state, even when I removed the RevisionPrefetchingPolicy.
>
> I filed a bugzilla here:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=318919
>
> Regards,
> Bastien.
>
--------------010000000106060405010806
Content-Type: multipart/related;
boundary="------------030204070308020800050501"
--------------030204070308020800050501
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
Are you using the new legacy mode? Maybe by accident?<br>
<br>
<!--WISESTAMP_SIG_12696_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.05090203.07000807@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.04040708.06090108@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.09000401.02010904@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.09030406.04060400@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_12696_END--><br>
<br>
Am 05.07.2010 18:46, schrieb Bastien:
<blockquote cite="mid:i0t2a3$dsc$1@build.eclipse.org" type="cite">Eike,
<br>
<br>
I already removed the
view.options().setRevisionPrefetchingPolicy(...) in my previous
post,I should have said so in order to be clearer, my apologies.
<br>
<br>
When the cdoPrefetch() method is called my root object is in CLEAN
state, even when I removed the RevisionPrefetchingPolicy.
<br>
<br>
I filed a bugzilla here:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=318919">https://bugs.eclipse.org/bugs/show_bug.cgi?id=318919</a>
<br>
<br>
Regards,
<br>
Bastien.
<br>
<br>
</blockquote>
</body>
</html>
--------------030204070308020800050501
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.05090203.07000807@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------030204070308020800050501
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.04040708.06090108@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------030204070308020800050501
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.09000401.02010904@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------030204070308020800050501
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.09030406.04060400@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------030204070308020800050501--
--------------010000000106060405010806--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #544914 is a reply to message #544882] |
Tue, 06 July 2010 04:44 |
|
This is a multi-part message in MIME format.
--------------070902070508000207080607
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
That might explain it. As far as I know lazy loading is not supported for legacy objects at all. We might be able to optimize that a little bit but in general the legacy mode is not well suited for large models.
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 05.07.2010 23:17, schrieb Bastien:
> Hum indeed I'm using it, I once had a problem with a model I wanted to commit, so I had to activate it.
>
> Regards,
> Bastien.
--------------070902070508000207080607
Content-Type: multipart/related;
boundary="------------000305080806080206060602"
--------------000305080806080206060602
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
That might explain it. As far as I know lazy loading is not
supported for legacy objects at all. We might be able to optimize
that a little bit but in general the legacy mode is not well suited
for large models.<br>
<br>
<!--WISESTAMP_SIG_69298_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.06070009.06000500@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.00070500.04000803@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.08060607.03050403@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.09000707.03010404@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_69298_END--><br>
<br>
Am 05.07.2010 23:17, schrieb Bastien:
<blockquote cite="mid:i0ti4g$l01$1@build.eclipse.org" type="cite">Hum
indeed I'm using it, I once had a problem with a model I wanted to
commit, so I had to activate it.
<br>
<br>
Regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------000305080806080206060602
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.06070009.06000500@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------000305080806080206060602
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.00070500.04000803@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------000305080806080206060602
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.08060607.03050403@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------000305080806080206060602
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.09000707.03010404@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------000305080806080206060602--
--------------070902070508000207080607--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #544940 is a reply to message #544914] |
Tue, 06 July 2010 07:21 |
Martin Fluegge
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hi Bastien,
yes. Sounds as if Legacy could be the root of the problem. ;(
As Eike mentioned there is some potential for optimization but I doubt that as long legacy does not support lazy loading it is well suited for models of your size.
Could you please file a bugzilla for this topic? Then we will see what we can do.
You mentioned that you had trouble with your model and that's why switched to legacy. What was this problem? Maybe we can help solving this (maybe it's even a bug)?
Cheers,
Martin
[Updated on: Tue, 06 July 2010 07:24] Report message to a moderator |
|
|
| Re: [CDO] Profiling CDO [message #544945 is a reply to message #542542] |
Tue, 06 July 2010 07:48 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Hi Martin and Eike,
I had to activate the legacy mode this friday (02/07) afternoon because the problem happened after I updated my cdo 3.0 version from v20100309 to v20100618
was the legacy mode implemented in the earlier version I used, and was it activated by default?
Edit: after verification, before this friday, I couldn't use legacy mode because of my earlier version of CDO v20100309.
Regards,
Bastien.
[Updated on: Tue, 06 July 2010 08:00] Report message to a moderator |
|
|
| Re: [CDO] Profiling CDO [message #544961 is a reply to message #544945] |
Tue, 06 July 2010 08:42 |
|
This is a multi-part message in MIME format.
--------------010605000600090303050306
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
So, what was that problem that you hoped to fix with using the legacy mode?
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 06.07.2010 09:48, schrieb Bastien:
> Hi Martin and Eike,
>
> I had to activate the legacy mode this friday (07/02) afternoonn because the problem happened after I updated my cdo 3.0 version from v20100309 to v20100618
> was the legacy mode implemented in the earlier version I used, and was it activated by default?
>
> Regards,
> Bastien.
>
>
--------------010605000600090303050306
Content-Type: multipart/related;
boundary="------------080500070000020309080905"
--------------080500070000020309080905
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
So, what was that problem that you hoped to fix with using the
legacy mode?<br>
<br>
<!--WISESTAMP_SIG_45878_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.07070802.04050606@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.06030806.06060908@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.03010204.00040802@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.09050004.00000200@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_45878_END--><br>
<br>
Am 06.07.2010 09:48, schrieb Bastien:
<blockquote cite="mid:i0un56$f8h$1@build.eclipse.org" type="cite">Hi
Martin and Eike,
<br>
<br>
I had to activate the legacy mode this friday (07/02) afternoonn
because the problem happened after I updated my cdo 3.0 version
from v20100309 to v20100618 <br>
was the legacy mode implemented in the earlier version I used, and
was it activated by default?
<br>
<br>
Regards,
<br>
Bastien.
<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------080500070000020309080905
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.07070802.04050606@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------080500070000020309080905
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.06030806.06060908@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------080500070000020309080905
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.03010204.00040802@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------080500070000020309080905
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.09050004.00000200@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------080500070000020309080905--
--------------010605000600090303050306--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #544965 is a reply to message #542542] |
Tue, 06 July 2010 08:56 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Eike,
Actually I commit several models (conform to different meta-models) on my CDO, and it's the commit of one of these model (always the same) which posed problem.
I had an error saying that the legacy mode was not activated, so I activated it and the commit worked.
regards,
Bastien.
[Updated on: Tue, 06 July 2010 09:04] Report message to a moderator |
|
|
| Re: [CDO] Profiling CDO [message #544967 is a reply to message #544945] |
Tue, 06 July 2010 08:44 |
|
Am 06.07.2010 09:48, schrieb Bastien:
> Hi Martin and Eike,
>
> I had to activate the legacy mode this friday (07/02) afternoonn because the problem happened after I updated my cdo 3.0 version from v20100309 to v20100618
> was the legacy mode implemented in the earlier version I used, and was it activated by default?
IIRC. that was approximately the period when we realized that the legacy mode accidentally was left on by default and changed the default to "off".
The question is still why you are thinking that you need the legacy mode, whether it's on by default or by your manual configuration?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #544968 is a reply to message #544945] |
Tue, 06 July 2010 08:45 |
|
This is a multi-part message in MIME format.
--------------020003090708040206020806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
Another question: Do your posts appear wrongly "rooted" only for me? Why don't you reply to the post that your reply should appear under?
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 06.07.2010 09:48, schrieb Bastien:
> Hi Martin and Eike,
>
> I had to activate the legacy mode this friday (07/02) afternoonn because the problem happened after I updated my cdo 3.0 version from v20100309 to v20100618
> was the legacy mode implemented in the earlier version I used, and was it activated by default?
>
> Regards,
> Bastien.
>
>
--------------020003090708040206020806
Content-Type: multipart/related;
boundary="------------050307070800000609010001"
--------------050307070800000609010001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
Another question: Do your posts appear wrongly "rooted" only for me?
Why don't you reply to the post that your reply should appear under?<br>
<br>
<!--WISESTAMP_SIG_39221_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.06030501.07010207@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.04020208.04010801@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.09000800.01030201@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.06010307.03070806@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_39221_END--><br>
<br>
Am 06.07.2010 09:48, schrieb Bastien:
<blockquote cite="mid:i0un56$f8h$1@build.eclipse.org" type="cite">Hi
Martin and Eike,
<br>
<br>
I had to activate the legacy mode this friday (07/02) afternoonn
because the problem happened after I updated my cdo 3.0 version
from v20100309 to v20100618 <br>
was the legacy mode implemented in the earlier version I used, and
was it activated by default?
<br>
<br>
Regards,
<br>
Bastien.
<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------050307070800000609010001
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.06030501.07010207@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------050307070800000609010001
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.04020208.04010801@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------050307070800000609010001
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.09000800.01030201@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------050307070800000609010001
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.06010307.03070806@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------050307070800000609010001--
--------------020003090708040206020806--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | | |
| Re: [CDO] Profiling CDO [message #544985 is a reply to message #544965] |
Tue, 06 July 2010 09:19 |
|
This is a multi-part message in MIME format.
--------------000305070906080601020604
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
This error message that you're referring to was basically telling you two things:
1) Your object was a legacy object (i.e. not generated for CDO).
2) Your transaction was not configured for legacy objects.
Generally you should try to fix it by changing point 1), i.e. regenerate your model for CDO. See http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO
Only if it's not possible or desirablefor mysterious resons you should consider to fix it by changing point 2).
There's more info here:
http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO
http://www.mftech.org/blog/pivot/entry.php?id=18
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 06.07.2010 10:56, schrieb Bastien:
> Eike,
> Actually I commit several models (conform to different meta-models) on my CDO, and it's the commit of one of these model (always the same) which posed problem.
> I had an error saying that the legacy mode was not activated, so I activated it and the commit worked.
>
> regards,
> Bastien.
>
>
>
--------------000305070906080601020604
Content-Type: multipart/related;
boundary="------------040906000308080508030205"
--------------040906000308080508030205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
This error message that you're referring to was basically telling
you two things:<br>
<br>
1) Your object was a legacy object (i.e. not generated for CDO).<br>
2) Your transaction was not configured for legacy objects.<br>
<br>
Generally you should try to fix it by changing point 1), i.e.
regenerate your model for CDO. See
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO">http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO</a><br>
<br>
Only if it's not possible or desirablefor mysterious resons you
should consider to fix it by changing point 2).<br>
<br>
There's more info here:<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO">http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO</a><br>
<a class="moz-txt-link-freetext" href="http://www.mftech.org/blog/pivot/entry.php?id=18">http://www.mftech.org/blog/pivot/entry.php?id=18</a><br>
<br>
<!--WISESTAMP_SIG_74949_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.03000209.08090503@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.01080507.07060405@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.02040704.00040801@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.08010005.02080702@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_74949_END--><br>
<br>
Am 06.07.2010 10:56, schrieb Bastien:
<blockquote cite="mid:i0ur4d$1gs$1@build.eclipse.org" type="cite">Eike,
<br>
Actually I commit several models (conform to different
meta-models) on my CDO, and it's the commit of one of these model
(always the same) which posed problem.
<br>
I had an error saying that the legacy mode was not activated, so I
activated it and the commit worked.
<br>
<br>
regards,
<br>
Bastien.
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------040906000308080508030205
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.03000209.08090503@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------040906000308080508030205
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.01080507.07060405@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------040906000308080508030205
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.02040704.00040801@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------040906000308080508030205
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.08010005.02080702@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------040906000308080508030205--
--------------000305070906080601020604--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #545001 is a reply to message #544993] |
Tue, 06 July 2010 10:26 |
|
This is a multi-part message in MIME format.
--------------010501090300070404020501
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Excellent ;-)
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 06.07.2010 12:09, schrieb Bastien:
> Hum in fact it was an issue in my code, consider it solved, the legacy mode is no longer used.
>
> regards,
> Bastien.
--------------010501090300070404020501
Content-Type: multipart/related;
boundary="------------060500070002000809090106"
--------------060500070002000809090106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Excellent ;-)<br>
<br>
<!--WISESTAMP_SIG_69427_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.05010909.06090701@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.09000103.08070605@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.07030308.01080903@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.09090300.06050000@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_69427_END--><br>
<br>
Am 06.07.2010 12:09, schrieb Bastien:
<blockquote cite="mid:i0uvc8$t8i$1@build.eclipse.org" type="cite">Hum
in fact it was an issue in my code, consider it solved, the legacy
mode is no longer used.
<br>
<br>
regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------060500070002000809090106
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.05010909.06090701@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------060500070002000809090106
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.09000103.08070605@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------060500070002000809090106
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.07030308.01080903@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------060500070002000809090106
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.09090300.06050000@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------060500070002000809090106--
--------------010501090300070404020501--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #545013 is a reply to message #545003] |
Tue, 06 July 2010 11:03 |
|
This is a multi-part message in MIME format.
--------------090200000101000805020902
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
I think this method should react to the prefetchDepth parameter of its calling method:
org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.createRevisionInfos(List <CDOID>, CDOBranchPoint, boolean, RevisionInfo[])
.... and only return RevisionInfo.Missing instances.
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 06.07.2010 12:34, schrieb Bastien:
> Eike,
>
> considering the scope of this bug (4.0 version):
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=318919
>
> Can you point me to the classes I should study in order for me to modify my local CDO installation (client and server side) and force the prefetching?
>
> Regards,
> Bastien.
>
--------------090200000101000805020902
Content-Type: multipart/related;
boundary="------------090903020605010107070005"
--------------090903020605010107070005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Bastien,<br>
<br>
I think this method should react to the prefetchDepth parameter of
its calling method:<br>
<br>
org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.createRevisionInfos(List<CDOID>,
CDOBranchPoint, boolean, RevisionInfo[])
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<br>
<br>
... and only return RevisionInfo.Missing instances.<br>
<br>
<!--WISESTAMP_SIG_38011_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.00040202.09070602@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.03060506.05030700@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.04000600.04010209@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.02000809.08080503@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_38011_END--><br>
<br>
Am 06.07.2010 12:34, schrieb Bastien:
<blockquote cite="mid:i0v0sb$a1b$1@build.eclipse.org" type="cite">Eike,
<br>
<br>
considering the scope of this bug (4.0 version):
<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=318919">https://bugs.eclipse.org/bugs/show_bug.cgi?id=318919</a>
<br>
<br>
Can you point me to the classes I should study in order for me to
modify my local CDO installation (client and server side) and
force the prefetching?
<br>
<br>
Regards,
<br>
Bastien.
<br>
<br>
</blockquote>
</body>
</html>
--------------090903020605010107070005
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.00040202.09070602@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------090903020605010107070005
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.03060506.05030700@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------090903020605010107070005
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.04000600.04010209@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------090903020605010107070005
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.02000809.08080503@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------090903020605010107070005--
--------------090200000101000805020902--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #545038 is a reply to message #545013] |
Tue, 06 July 2010 13:44 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Eike,
Thanks for the tip, I've had already located this method, but a confirmation is always welcome 
I did some modification by my side:
First, I modified the
org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.createRevisionInfos(List <CDOID>, CDOBranchPoint, boolean, RevisionInfo[]) for it to return all kinds of revision infos.
then I had to modify org.eclipse.emf.cdo.internal.server.Repository.loadRevisions (List <RevisionInfo> infos, CDOBranchPoint branchPoint, int referenceChunk, int prefetchDepth) method,
basically I removed the whole switch about the RevisionInfo.Type
With these modifications, the CDOObject#cdoPrefetch() method is working effectively, but there's still a little issue, indeed, I have a TimeOutException after 10seconds.
I tried to use this: connector.setOpenChannelTimeout(IConnector.NO_CHANNEL_TIMEOU T); but I still have a timeout after 10 seconds. Is there an option to add in my server configuration for example?
Regards,
Bastien.
|
|
|
| Re: [CDO] Profiling CDO [message #545107 is a reply to message #545038] |
Tue, 06 July 2010 16:11 |
|
Am 06.07.2010 15:44, schrieb Bastien:
> Eike,
>
> Thanks for the tip, I've had already located this method, but a confirmation is always welcome ;)
>
> I did some modification by my side:
>
> First, I modified the org.eclipse.emf.cdo.internal.common.revision.CDORevisionMana gerImpl.createRevisionInfos(List <CDOID>, CDOBranchPoint, boolean, RevisionInfo[]) for it to return all kinds of revision infos.
>
> then I had to modify org.eclipse.emf.cdo.internal.server.Repository.loadRevisions (List <RevisionInfo> infos, CDOBranchPoint branchPoint, int referenceChunk, int prefetchDepth) method, basically I removed the whole switch about the RevisionInfo.Type
Why don't you attach a patch to the bugzilla you submitted? Then it'd be easier to talk about it ;-)
>
> With these modifications, the CDOObject#cdoPrefetch() method is working effectively, but there's still a little issue, indeed, I have a TimeOutException after 10seconds.
That doesn't sound reasonable for a Signal that should have the major payload in the respsone and the root cause should be investigated. Note that the timer expires only after a period of no incoming data at the client and is reset if more data arrives before expiration. It's not a total request-start/response-end timeout!
>
> I tried to use this: connector.setOpenChannelTimeout(IConnector.NO_CHANNEL_TIMEOU T); but I still have a timeout after 10 seconds.
I doubt that the OpenChannelTimeout would help here. You may want to change the Signal read timeout via ISignalProtocol.setTimeout(long). For a CDOSession that's available via org.eclipse.emf.cdo.net4j.CDOSession.Options.getProtocol().
> Is there an option to add in my server configuration for example?
Not that I know of ;-(
>
> Regards,
> Bastien.
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Profiling CDO [message #545246 is a reply to message #545232] |
Wed, 07 July 2010 09:50 |
|
This is a multi-part message in MIME format.
--------------050506050305010005000307
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
The server does what the client requests. Of course the repository has an own revision cache to optimize back-end accesses.
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 07.07.2010 11:34, schrieb Bastien:
> Hi Eike,
> I added this line in my retreival code :
> session.options().getProtocol().setTimeout(300000L);
> Then the prefetching is working properly :)
>
> But I still have a few questions!
> Here's the use case:
> -This model is uploaded once on the server,
> -Several clients need to retreive it, but each of them once.
>
> that's my I'm wondering if, for every client which have to retreive this model, the server will do the prefetching.
>
> Regards,
> Bastien.
>
--------------050506050305010005000307
Content-Type: multipart/related;
boundary="------------010305090206050809060401"
--------------010305090206050809060401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Bastien,<br>
<br>
The server does what the client requests. Of course the repository
has an own revision cache to optimize back-end accesses.
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<br>
<br>
<!--WISESTAMP_SIG_70556_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.02060101.02000405@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.08050709.03030707@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.07090202.04070203@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.01080408.00040402@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_70556_END--><br>
<br>
Am 07.07.2010 11:34, schrieb Bastien:
<blockquote cite="mid:i11hm8$c9a$1@build.eclipse.org" type="cite">Hi
Eike,
<br>
I added this line in my retreival code :
<br>
session.options().getProtocol().setTimeout(300000L);
<br>
Then the prefetching is working properly :)
<br>
<br>
But I still have a few questions!
<br>
Here's the use case:
<br>
-This model is uploaded once on the server,
<br>
-Several clients need to retreive it, but each of them once.
<br>
<br>
that's my I'm wondering if, for every client which have to
retreive this model, the server will do the prefetching.
<br>
<br>
Regards,
<br>
Bastien.
<br>
<br>
</blockquote>
</body>
</html>
--------------010305090206050809060401
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.02060101.02000405@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------010305090206050809060401
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.08050709.03030707@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------010305090206050809060401
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.07090202.04070203@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------010305090206050809060401
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.01080408.00040402@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------010305090206050809060401--
--------------050506050305010005000307--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #545276 is a reply to message #545246] |
Wed, 07 July 2010 10:50 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Eike,
Thanks for the infos, what I wanted to know was, are the revisions prefetched by cdoPrefetch() stored server or client side?
I've done some tests with different clients (on different machines), these revisions seems to be stored in the cache server side.
first client prefetching: 122998ms
first local copying: 1749ms
second client prefetching: 1235ms
second local copying: 1734ms
Given that I have lots of models on my CDO, and the fact that they can be retreived at any time, my feeling is that I need a big cache server side to store a lot of revisions.
Regards,
Bastien.
[Updated on: Wed, 07 July 2010 10:50] Report message to a moderator |
|
|
| Re: [CDO] Profiling CDO [message #545300 is a reply to message #545276] |
Wed, 07 July 2010 11:25 |
|
Am 07.07.2010 12:50, schrieb Bastien:
> Eike,
>
> Thanks for the infos, what I wanted to know was, are the revisions prefetched by cdoPrefetch() stored server or client side?
The word "stored" confuses me. I guess you're really meaning "cached".
The repository caches as many revisions as it can to reduce reloading them from the storage back-end.
The client caches as many revisions as it can to reduce reloading them from the repository.
> I've done some tests with different clients (on different machines), they seems to be stored server side.
>
> first client prefetching: 122998ms
> first local copying: 1749ms
>
> second client prefetching: 1235ms
> second local copying: 1734ms
Makes sense.
>
> Given that I have lots of models on my CDO, and the fact that they can be retreived at any time, my feeling is that I need a big cache server side to store a lot of revisions.
Also sounds like a good idea ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #545337 is a reply to message #545300] |
Wed, 07 July 2010 13:20 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Eike,
First of all, I would like to precise that in my previous post, when I wrote "first client / second client", I litterally meant it: the second client fetching was performed from another workstation.
So it seems to me, as confirmed by the second test (3s to fetch our model from a second client), that the network protocol is not the bottleneck anymore.
To confirm this analysis, we captured the TCP traffic of the previous tests. In both cases, the impact of my modification was significant: only 10 requests from the client to the server.
My feeling is that most of the time is now spent requesting the storage back-end in order to construct the server cache.
2 minutes seems a long time for such an operation, considering that my test model weights 3Mo and has about 50000 elements.
Do you have any advices to improve the back-end storage?
For now I'm using mysql, and my mapping strategy is horizontalNonAudit.
Given that my goal is to retreive the wholeness of my model, I'm in a situation where lazy loading shouldn't be used.
Regards,
Bastien.
|
|
|
| Re: [CDO] Profiling CDO [message #545392 is a reply to message #545337] |
Wed, 07 July 2010 15:46 |
|
This is a multi-part message in MIME format.
--------------060307090006070407070701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
You could open an embedded session in the repository and have a background thread preload and cache the often used resources. As you noticed, a large cache also helps (not configurable anymore). We use H2 as our default test DB and it seems pretty fast.
Stefan might remember if horizontalNonAudit mapping strategy is the most optimized one. I recall something like "WithRanges" optimization, but that might be a write optimization...
We might also consider more back-end protocol optimizations but I guess that effort needs to be funded somehow, given that you can have optimal results already with small workarounds like the aforementioned preload-thread.
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 07.07.2010 15:20, schrieb Bastien:
> Eike,
>
> First of all, I would like to precise that in my previous post, when I wrote "first client / second client", I litterally meant it: the second client fetching was performed from another workstation.
>
> So it seems to me, as confirmed by the second test (3s to fetch our model from a second client), that the network protocol is not the bottleneck anymore.
>
> To confirm this analysis, we captured the TCP traffic of the previous tests. In both cases, the impact of my modification was significant: only 10 requests from the client to the server.
>
> My feeling is that most of the time is now spent requesting the storage back-end in order to construct the server cache.
> 2 minutes seems a long time for such an operation, considering that my test model weights 3Mo and has about 50000 elements.
>
> Do you have any advices to improve the back-end storage?
> For now I'm using mysql, and my mapping strategy is horizontalNonAudit.
>
> Given that my goal is to retreive the wholeness of my model, I'm in a situation where lazy loading shouldn't be used.
>
> Regards,
> Bastien.
--------------060307090006070407070701
Content-Type: multipart/related;
boundary="------------060904070109050104010608"
--------------060904070109050104010608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Bastien,<br>
<br>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
You could open an embedded session in the repository and have a
background thread preload and cache the often used resources. As you
noticed, a large cache also helps (not configurable anymore). We use
H2 as our default test DB and it seems pretty fast.<br>
<br>
Stefan might remember if horizontalNonAudit mapping strategy is the
most optimized one. I recall something like "WithRanges"
optimization, but that might be a write optimization...<br>
<br>
We might also consider more back-end protocol optimizations but I
guess that effort needs to be funded somehow, given that you can
have optimal results already with small workarounds like the
aforementioned preload-thread.<br>
<br>
<!--WISESTAMP_SIG_60067_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.00080203.05090604@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.04010702.00080605@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.00040102.01010802@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.08040903.00030307@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_60067_END--><br>
<br>
Am 07.07.2010 15:20, schrieb Bastien:
<blockquote cite="mid:i11uvc$1gb$1@build.eclipse.org" type="cite">Eike,
<br>
<br>
First of all, I would like to precise that in my previous post,
when I wrote "first client / second client", I litterally meant
it: the second client fetching was performed from another
workstation.
<br>
<br>
So it seems to me, as confirmed by the second test (3s to fetch
our model from a second client), that the network protocol is not
the bottleneck anymore.
<br>
<br>
To confirm this analysis, we captured the TCP traffic of the
previous tests. In both cases, the impact of my modification was
significant: only 10 requests from the client to the server.
<br>
<br>
My feeling is that most of the time is now spent requesting the
storage back-end in order to construct the server cache. <br>
2 minutes seems a long time for such an operation, considering
that my test model weights 3Mo and has about 50000 elements.
<br>
<br>
Do you have any advices to improve the back-end storage?
<br>
For now I'm using mysql, and my mapping strategy is
horizontalNonAudit.
<br>
<br>
Given that my goal is to retreive the wholeness of my model, I'm
in a situation where lazy loading shouldn't be used.
<br>
<br>
Regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------060904070109050104010608
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.00080203.05090604@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------060904070109050104010608
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.04010702.00080605@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------060904070109050104010608
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.00040102.01010802@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------060904070109050104010608
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.08040903.00030307@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------060904070109050104010608--
--------------060307090006070407070701--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Profiling CDO [message #545547 is a reply to message #545392] |
Thu, 08 July 2010 08:03 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Bastien, Eike,
> You could open an embedded session in the repository and have a
> background thread preload and cache the often used resources. As you
> noticed, a large cache also helps (not configurable anymore). We use
> H2 as our default test DB and it seems pretty fast.
Bastien, if you are able to try with H2, then this would help in
identifying the bottleneck.
If it is the database, then custom database optimizations (such as
partitioning) could help. So if you have some DB optimization/profiling
knowledge (or maybe you have a DB-guru at hand) then have a look if
there's any SQL that requires too much time. Maybe there is a column
index missing during CDO setup.
Also, on the DB-side,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=305962 is still open which
could result in a bottleneck of objects are read more than once (ok,
seems not to be the case for you).
>
> Stefan might remember if horizontalNonAudit mapping strategy is the
> most optimized one. I recall something like "WithRanges" optimization,
> but that might be a write optimization...
It is an optimization for the auditmode and yes, it optimizes storing
more than reading ... So, if you don't need audit-mode, then the
non-audit strategy is more optimized.
Cheers,
Stefan
|
|
| |
| Re: [CDO] Profiling CDO [message #546224 is a reply to message #545547] |
Mon, 12 July 2010 08:37 |
Bastien
Messages: 44
Registered: March 2010 |
Member |
|
|
Hi Stefan,
I did some tests since my last post.
I am still using the same test model:
- 3Mo size
- about 50 000 model elements
- maximum depth: 7
I measured the performances with H2 and Mysql
Prefetching time server side:
- H2: between 60 and 80 seconds
- Mysql: between 120 and 130 seconds
Local copy of the model:
both about 1 or 2 seconds.
The gain with H2 is between 30 and 50%, but I still think 60 or 80 sec is too much for the retreival of a 50 000 elements sized model.
So, I managed to get the sql trafic between jdbc and the databases, and I could analyse a 4 requests pattern:
SET OPTION SQL_SELECT_LIMIT=DEFAULT
SELECT cdo_class FROM cdo_objects WHERE cdo_id=123
SET OPTION SQL_SELECT_LIMIT=1
SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, vt_data, value FROM MyMetamodel_MymodelElement WHERE cdo_id=123 AND (cdo_revised=0)
I'm not sure if the SET OPTIONS resquests are relevant here (maybe generated by jdbc), but I think It should be possible to decrease the amount of SELECT requests by combining the two of them.
Considering these informations, I'm actually working on some back-end modifications in order to do some other measurements.
Regards,
Bastien.
|
|
|
| Re: [CDO] Profiling CDO [message #546275 is a reply to message #546224] |
Mon, 12 July 2010 11:11 |
|
This is a multi-part message in MIME format.
--------------050706010705040501020704
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Bastien,
Comments below...
Cheers
/Eike
Contact: http://www.esc-net.de Blogger <http://thegordian.blogspot.com>Twitter <http://twitter.com/eikestepper>Linkedin <http://de.linkedin.com/in/eikestepper>Xing <http://www.xing.com/profile/Eike_Stepper>
Article: What exactly is inside that p2 repository? < http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html>
Am 12.07.2010 10:37, schrieb Bastien:
> Hi Stefan,
> I did some tests since my last post.
> I am still using the same test model:
> - 3Mo size
What does that mean?
> - about 50 000 model elements
> - maximum depth: 7
>
> I measured the performances with H2 and Mysql
> Prefetching time server side:
> - H2: between 60 and 80 seconds
> - Mysql: between 120 and 130 seconds
> Local copy of the model:
> both about 1 or 2 seconds.
>
> The gain with H2 is between 30 and 50%, but I still think 60 or 80 sec is too much for the retreival of a 50 000 elements sized model.
> So, I managed to get the sql trafic between jdbc and the databases, and I could analyse a 4 requests pattern:
>
> SET OPTION SQL_SELECT_LIMIT=DEFAULT
> SELECT cdo_class FROM cdo_objects WHERE cdo_id=123
> SET OPTION SQL_SELECT_LIMIT=1
> SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, vt_data, value FROM MyMetamodel_MymodelElement WHERE cdo_id=123 AND (cdo_revised=0)
>
> I'm not sure if the SET OPTIONS resquests are relevant here (maybe generated by jdbc), but I think It should be possible to decrease the amount of SELECT requests by combining the two of them.
I doubt that. Note that the second query string (the FROM clause in particular) can only be concatenated from the result of the first one. But of course we'd be happy if you could prove us wrong ;-)
>
> Considering these informations, I'm actually working on some back-end modifications in order to do some other measurements.
>
> Regards,
> Bastien.
--------------050706010705040501020704
Content-Type: multipart/related;
boundary="------------060901020200050006080303"
--------------060901020200050006080303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Bastien,<br>
<br>
Comments below...<br>
<br>
<!--WISESTAMP_SIG_27611_START--><span style="color: black;">
<div dir="ltr">
<div>Cheers
<br>
/Eike
<br>
<br>
</div>
<div style="padding: 5px 0pt; font-family: arial,sans-serif;
font-size: 13.3px;"><span style="color: gray;">Contact: <a
href="http://www.esc-net.de">http://www.esc-net.de</a></span>
<a href="http://thegordian.blogspot.com" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part1.06070700.04050309@esc-net.de" alt="Blogger"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://twitter.com/eikestepper" style="padding: 0pt
2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part2.09060805.08090802@esc-net.de" alt="Twitter"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a><a
href="http://de.linkedin.com/in/eikestepper" style="padding:
0pt 2px; color: blue; font-size: 10pt;" _service=""><img
src="cid:part3.06060700.01000603@esc-net.de"
alt="Linkedin" style="vertical-align: middle;
padding-bottom: 5px;" border="0" height="16" width="16"></a><a
href="http://www.xing.com/profile/Eike_Stepper"
style="padding: 0pt 2px; color: blue; font-size: 10pt;"
_service=""><img
src="cid:part4.00020204.03010600@esc-net.de" alt="Xing"
style="vertical-align: middle; padding-bottom: 5px;"
border="0" height="16" width="16"></a></div>
<div style="color: gray; font-size: 13.3px; padding-bottom:
5px;">Article: <span style="color: blue; text-decoration:
underline;"><a
href=" http://thegordian.blogspot.com/2010/05/what-exactly-is-insid e-that-p2.html"
undefined="">What exactly is inside that p2 repository?</a></span></div>
</div>
</span><!--WISESTAMP_SIG_27611_END--><br>
<br>
Am 12.07.2010 10:37, schrieb Bastien:
<blockquote cite="mid:i1ek8p$jbl$1@build.eclipse.org" type="cite">Hi
Stefan,
<br>
I did some tests since my last post.
<br>
I am still using the same test model:
<br>
- 3Mo size
<br>
</blockquote>
What does that mean?<br>
<br>
<blockquote cite="mid:i1ek8p$jbl$1@build.eclipse.org" type="cite">-
about 50 000 model elements
<br>
- maximum depth: 7
<br>
<br>
I measured the performances with H2 and Mysql
<br>
Prefetching time server side:
<br>
- H2: between 60 and 80 seconds
<br>
- Mysql: between 120 and 130 seconds
<br>
Local copy of the model:
<br>
both about 1 or 2 seconds.
<br>
<br>
The gain with H2 is between 30 and 50%, but I still think 60 or 80
sec is too much for the retreival of a 50 000 elements sized
model.
<br>
So, I managed to get the sql trafic between jdbc and the
databases, and I could analyse a 4 requests pattern:
<br>
<br>
SET OPTION SQL_SELECT_LIMIT=DEFAULT
<br>
SELECT cdo_class FROM cdo_objects WHERE cdo_id=123
<br>
SET OPTION SQL_SELECT_LIMIT=1
<br>
SELECT cdo_version, cdo_created, cdo_revised, cdo_resource,
cdo_container, cdo_feature, vt_data, value FROM
MyMetamodel_MymodelElement WHERE cdo_id=123 AND (cdo_revised=0)
<br>
<br>
I'm not sure if the SET OPTIONS resquests are relevant here (maybe
generated by jdbc), but I think It should be possible to decrease
the amount of SELECT requests by combining the two of them.
<br>
</blockquote>
I doubt that. Note that the second query string (the FROM clause in
particular) can only be concatenated from the result of the first
one. But of course we'd be happy if you could prove us wrong ;-)<br>
<br>
<blockquote cite="mid:i1ek8p$jbl$1@build.eclipse.org" type="cite">
<br>
Considering these informations, I'm actually working on some
back-end modifications in order to do some other measurements.
<br>
<br>
Regards,
<br>
Bastien.
<br>
</blockquote>
</body>
</html>
--------------060901020200050006080303
Content-Type: image/png;
name="blogger.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.06070700.04050309@esc-net.de>
Content-Disposition: inline;
filename="blogger.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAABGdBTUEAAK/I NwWK6QAAABl0
RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAADkUExURf9xEv9m AP////9lAP+Q
SP9kAP9jAP9fAP9nAf9vD//x5/9hAP/iz/9iAP9eAP/s4P9vEP9yEv9qAP9q B/+LRP+we/90
I/+RSP/z6/+jZv/y6P+8kP/59f5yE//awf/Ttv9hAf9nAv/17v+4if9sC/9o BP+bWP/r3v/k
0v+wfP+QRv/o2f9gAP+OQ/93HP/l0/+0gv/Rsv/9/P/j0P+pcP+0hf/dx//D m//+/v+td/9o
AP+NQv/Yvf+zgv/x6P/q2/9xG//p2f9pAP/s3//8+fxxE//ex/+AK/9oCP/j 0f/Uuv///4Xw
StcAAABMdFJOU/////////////////////////////////////////////// ////////////
/////////////////////////////////////////wCejeTMAAAAsklEQVR4 2kSP1w6DMBAE
7cMGQg0hvffee++d//+f2IaIeTlppNXtIo88UAjxEIlhjCUG5lwJQuwoulqh FuUGcWGSiTF7
bt40EEoXBKtyIPQS5PffFqyHlhCS2obTK5kDmJ8lXxgA0zsPXer0L3zSUVmI D9ip3SC+hKwQ
2CxCtXYYL25gu1S8bf4jib5fTM+MNE079jom/+KwJUojwnAVifcQ46jM4M23 BHmkEK53iPcT
YACE/Q4KzoVQVwAAAABJRU5ErkJggg==
--------------060901020200050006080303
Content-Type: image/png;
name="twitter.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.09060805.08090802@esc-net.de>
Content-Disposition: inline;
filename="twitter.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAABxUlE QVQ4y4WTMW4U
QRBFX3X3zoy8FgZphTCYAEg4gAPEYbgBJEgEXIALkHMfAjIwItnAAfLK2JYB r3dmuj7BzI5m
2WBLqqzq//q/fxt9NTmrzo7MCIhgRpWSsaMSgEta5czcjYtWTKPxfALZXTEE 2wmAxLXD11VL
BZy2MAuJB/iuA3oAoJb4lUUCVkAGTM5t06gjATMjBiPFaFsADvx1MTFoBd/q zHkMeLcLgCEe
JqjbrCJ1IAkghGDz20Z/XEzMMMTnZTsSYANMAl7fq7YlZOBaUCCk4WowwyRA mBmL7CxcmwDu
rh+rzKU71YhQ/dnr8VbiaRF4MgmbAAZkxJU7lRk3Wby5W3FcJlbSICAjZjFS jJ42rSXWgoWL
fYPfLvaCMTVxJ0XoJTmQ/stF6GPABDhzcepi7uJ74yQDuXcDErjjGhkwNvHx xCjMOMkCg3eX
S85zyVEMtGt24GWVxvsM5yi3+nBV8/7iBmJv0gaZQMZhNL4cHXBYdDkY7HQL vD0oebVfQuud
a8FGHSAaP1vnpMmbHgDEECwafLq/x8fZlGfJKCVKiapvXLyoEsdl3JYwBMpd uW1YEjlz4aMh
AY+iURiU/Vf/B6EE4kjfs5YLAAAAAElFTkSuQmCC
--------------060901020200050006080303
Content-Type: image/png;
name="linkedin.png"
Content-Transfer-Encoding: base64
Content-ID: <part3.06060700.01000603@esc-net.de>
Content-Disposition: inline;
filename="linkedin.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABmJLR0QA/wD/ AP+gvaeTAAAA
CXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAQAAAAEABcxq3DAAACGklE QVQ4y6WTO2sU
URTHf3dmdp0kTnZJzErSrPjKYqNY2GljodhoLRLB1sLCD2DrZxAsfCAE/AaC grY+SBQSFTSC
xizGzZ3MTiYz92UxY5KNYuOBP+eew/3/73lwxfWHT9yjuR8YL0CwyxygAAPo Cqr0ntFcvjBB
cH++x8WzJzm8v/EnWVdks0PEgNWO95/XePD4HZ4ADk6MAhD6Hs26/08yBjwr ODrZBK0JADyv
LP7GsX2Evse9xR5Lsvgr+XfsO7ctoKwj9AWh7wEQIFCF+3sFGjCmgiJwQFwY Yge3X3cZrwXM
r2SDg9tJ1rokaw1alRXI3NAO61w60AAHTkE7qtNu1PjSUywsb3L60AgjNcHz hZgXb39WApoA
C3FqsIGjMxYC8OZbxlQU0GmFTLdCznWireV0pobYSDKevuzilMZDg0wN/cxu XdrMLVqX53TT
cu3OJ87cmmdlrQBgemoYKTMwqhSI+4Z0QMBhjANgcTnj1UdJHGd8Xc0AmBit Ecu0moGGODH0
h7cF8tyidSmgjSWWG6AUWpkypw1xLwXA4z8tQINcN/T3moEWtLZbr0mZQV5s 55RFJuU8RHR1
1iWtIzQ8nxOtIVCw9D2lWbM06w4ZZ8wtrEJRcLw9TDMUyKRg7kOPSHQR0ZVZ lyRjMDkOOVAU
FfLS57viHRaJLsHM+THuPtuDUgLTW2U0X672t47rrw82vOu/z9w8xS+MkDzV Boy6+QAAAABJ
RU5ErkJggg==
--------------060901020200050006080303
Content-Type: image/png;
name="xing.png"
Content-Transfer-Encoding: base64
Content-ID: <part4.00020204.03010600@esc-net.de>
Content-Disposition: inline;
filename="xing.png"
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAACXBIWXMAAAsT AAALEwEAmpwY
AAABsklEQVR42mP8//8/AymAEb+G1x9333hU9fffZy52ZTONrQQ0/P7z7sLd hJfvN7Mw80mL
ROkqTodqAIKvv379+fuXhZmZh50dpv7f49dLLt1LYWD4ryRZCETsrJIIDYdu 3y5fu16AizPE
0CTFzgoo8fPXoxPX/T9/v8DHbWCito6LXRHFDw/evnXpm3D39Ws1Eck9xVmy wqLP3/SevlXC
ysKtLtuoJFmMxdObL17ymzqN8S9LnZddua/VrUcWD149FRNwNFFby8oiiEXD itNnImfN5WTi
nBhu7Gvw5OLdiv+MQnqKU6WEI7AE6+vPnx17+68+fmGrJL0wRe/rl/jbL94r isfqKs1kZuJE
1/Dt16/27TtatmzjYeZcnuZpqnDi3J16FmZxYDhKCAViibiVp8+Ur1v39N0H X12DFRkJ33/u
O3LVk+E/i5xYqq7iNCwaXn769PLTZ0ZGBnFePjE+3j9/3155kPvk9XIudgV9 5XnCfI6Ek8a7
T4dO3vD4+++HlHC4kepywhr+/P0ITEIPXk5jZxXTVpgE1EY48X36euHs7fBv P+8CVespzYGH
FSOpyRsAAuDh4a3m5z0AAAAASUVORK5CYII=
--------------060901020200050006080303--
--------------050706010705040501020704--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 26 11:44:13 GMT 2024
Powered by FUDForum. Page generated in 0.04974 seconds |
] 
Search
Help
Register
Login
Home
