[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: 答复: [cross-project-issues-dev] Pack200 problem?
|
update manager only downloads the packed
files (pack.gz) if it knows that it has access to the unpack200 executable
(e.g., if Java5 or later is installed). so you should not see this
problem. You might be running into a bug...
Jeff
"Xiaoying Gu"
<xgu@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
12/09/2006 11:47 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
|
To
| "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| 答复: [cross-project-issues-dev] Pack200
problem? |
|
But if the JDK installed on users machine is 1.4.X
and he downloaded JAR file from update manger, how can it unpack the .pack.gz
file included in jar file?
I encountered the problem when I update using these jars. The unpacked
jars still contain .pack.gz file.
I don't know if it's the Update manger's problem or the update site jars'
problem...
I've attached the created update site jars.
Thanks,
Xiaoying Gu
________________________________
From: cross-project-issues-dev-bounces@xxxxxxxxxxx 代表 Jeff McAffer
Sent: 12/9/2006 (星期六) 6:51 上午
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Pack200 problem?
yes. the same JAR processor used to recursively pack JARs is used
to recursively unpack them. Update Manager should just take care
of this.
Jeff
"Xiaoying Gu" <xgu@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
12/09/2006 09:30 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
To
"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
[cross-project-issues-dev] Pack200 problem?
I'm using pack200 to optimizerize the update site with following ant script:
<java jar="d:/eclipse/startup.jar"
fork="true"
timeout="10800000"
jvm="${java15-home}/bin/java"
failonerror="true"
maxmemory="512m"
dir="d:/">
<arg line="-application org.eclipse.update.core.siteOptimizer"/>
<arg line="-jarProcessor -outputDir d:/test -processAll
-pack -repack d:/updates"/>
</java>
After execute the script, I found those plugins (.jar file) which need
to be unpacked after updating are changed also. Those jar file included
in the update jar (.jar file) were changed to .pack.gz.
Is this normal? I thought these jar file should remain the same as original
jar file. This cause the problem on our update site using these jars.
Does it need more steps on these plugins which need to be unpacked after
updating.
Thanks,
Xiaoying Gu
________________________________
From: cross-project-issues-dev-bounces@xxxxxxxxxxx 代表 Denis Roy
Sent: 12/8/2006 (星期五) 7:26 上午
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Degraded respons times from eclipse.org
Performance issues? We're listening.
Here's what we're doing to look into the problems:
- Wiki: We found two issues, one of which has been solved. The other: wiki
is *not* in the QoS [1], so its performance will vary as our bandwidth
saturation varies. There's a technological limitation blocking us from
putting the Wiki in QoS, but we'll work on it if performance problems persist.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=166401
- download.eclipse.org: if you download from our servers during busy times,
it'll be slow. This is by design, as most other services (except wiki!)
get top-priority access to bandwidth. Under heavy saturation, it is not
uncommon to only get 70KB/sec from an http download from download.eclipse.org.
- Bugzilla: I've been repeating this for decades. Bugzilla has database
table locking issues in its design. This is discussed here https://bugs.eclipse.org/bugs/show_bug.cgi?id=153818
We're working on solutions, but it's not easy.
- SSH/CVS: Although these services are in QoS, they are slow when we're
heavily saturated, likely because they must perform DNS lookups before
allowing the connection, which will introduce lag. Once connected, everything
flies due to the service being in QoS. Because we use our ISP's servers
for DNS, we're investigating installing a caching DNS server within our
network to avoid DNS lookups contending with bandwidth saturation.
- Overall, we're negociating an additional 10 Mbps of bandwidth. This
would increase our committed rate to 70 Mbps. If this doesn't last
us for a while, then someone somewhere is wasting.
- More CPUs: although it's not (yet) a bottleneck, our CPU usage has slowly
been increasing. Our systems were designed with scalability in mind, so
we have purchased another front-end processing server for the cluster.
This fifth node will decrease our CPU load considerably. You can see the
details here: http://eclipsewebmaster.blogspot.com/2006/12/node5-has-arrived.html
- Overall, I'm encouraging committers to clean up their disk space usage.
More files take up more space and cause longer replication and tape backup
times, stressing the disk systems during peak hours.
[1] http://en.wikipedia.org/wiki/QoS
Denis
John Arthorne wrote:
I've been doing
a lot of wiki editing this morning so I can throw in another data point
(from Ottawa). I found the performance to be highly variable. At
first it was taking 5-10 seconds to load a page, and 30+ seconds to commit
a modification. After awhile (perhaps coincidentally) it became positively
snappy. Towards the end I was getting 1-2 seconds to load a page,
and 2-5 seconds for a commit, depending on page size. I don't know
if this is because of caching, or because external factors were affecting
QoS. Denis, if you have created a bug, can you post the link here?
We could all provide further data in the bug to help narrow down
the problem.
Jeff McAffer/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
01/12/2006 10:35 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
To
henrik.lindberg@xxxxxxxxxxxxxx, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
RE: [cross-project-issues-dev] Degraded respons times from ecipse.org
Here is my 2c for
addressing wiki performance if possible. Editiing is a bit scary
and reading is slow enough that I now hesitate to put frequently used info
there because it takes too long to access. This sort of defeats the
purpose of having a wiki.
Jeff
"Henrik Lindberg" <henrik.lindberg@xxxxxxxxxxxxxx> <mailto:henrik.lindberg@xxxxxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
12/01/2006 07:21 AM
Please respond to
henrik.lindberg@xxxxxxxxxxxxxx; Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
To
<cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
RE: [cross-project-issues-dev] Degraded respons times from ecipse.org
Hi,
I don’t have
a problem with login taking long time per se (it is just once in a while
you have to wait), but wiki is intermittently very slow �C esp. when saving
edits. I can’t say I have found a pattern in its behavior (hour of day,
day of week etc.) except that it has gotten worse. The speed is so bad,
and it is quite scary when saves take long time (you start to distrust
the system, and feel you need to make a copy before saving if it crashes
etc.). For me it has gone as far as I am editing at another wiki first.
Naturally a lot of time is wasted. It would be very good if something could
be done about the wiki performance.
Also have problem
with Bugzilla being incredibly slow.
- henrik
>Mike Milinkovich
wrote:
>>That being
said, the Wiki has, for some unknown reason, started to lag by about 30
seconds when you access it for the first
>>time...
There's a caching issue that I don't yet understand, but I'll open a bug
for it as it's annoying.
>Can Thomas
and Doug comment on this? Are *your* wiki usage problems just on
>first access
or all the time?
_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
________________________________
_______________________________________________
cross-project-issues-dev
mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Attachment:
winmail.dat
Description: Binary data