Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 325811 - signing process is excruciatingly slow
Summary: signing process is excruciatingly slow
Status: RESOLVED FIXED
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Servers (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 blocker (vote)
Target Milestone: ---   Edit
Assignee: Eclipse Webmaster CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 325870 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-21 01:58 EDT by David Williams CLA
Modified: 2010-09-21 16:18 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2010-09-21 01:58:39 EDT
Something is up with the "new" signing process ... I think. Granted, I've only tried twice (neither of which has completed) ... but its been a couple of hours now and while its always seemed slow ... never _this_ slow. 

From watching the "tail" of signing log, it updates only every 2 to 5 minutes. 
With only my signing requests ... so I assume I am only one signing while watching ... assuming all the signing is still "intermingled" in same log? 

Not sure what's going on ... but don't think current speed will be usable. 


Minor note: I had previously hard code the signing invocation with 
/usr/bin/sign ... 
that now fails and I see it's moved to 
/usr/local/bin/sign 

guess that'll teach me. Just wanted to let you know such changes effects "us" users (on top of everything else). Not sure why I'd previously hard coded it ... but just using "sign" currently works ... I'll let the OS find it. Just thought I'd let you know.
Comment 1 David Williams CLA 2010-09-21 11:31:23 EDT
My attempts to sign eventually failed since were running for 8 hours or so. 

So ... I'm setting severity to 'blocker' to be more accurate that its not just "slow", but basically unusable as is.
Comment 2 Denis Roy CLA 2010-09-21 11:46:43 EDT
*** Bug 325870 has been marked as a duplicate of this bug. ***
Comment 3 Denis Roy CLA 2010-09-21 11:47:22 EDT
Seems like it's waiting several seconds for the timestamp.  We has this problem earlier, so I'll try using another JDK.
Comment 4 Denis Roy CLA 2010-09-21 13:03:22 EDT
I've switched to /opt/public/common/ibm-java-x86_64-60/bin/jarsigner and /opt/public/common/ibm-java-x86_64-60/bin/java and judging by the logs, things seem to have picked up.
Comment 5 Kim Moir CLA 2010-09-21 13:14:31 EDT
So if we have a signing process that entered the queue earlier, it will be running with the older and slower executables? Just wondering if I should restart our signing process for M2a.
Comment 6 Denis Roy CLA 2010-09-21 13:20:53 EDT
It should pick up the pace and continue, since the culprit was the thousands of calls to jarsigner.
Comment 7 Kim Moir CLA 2010-09-21 13:37:10 EDT
Thanks Denis. I can see the signed zip for our M2a build is now available.
Comment 8 Kim Moir CLA 2010-09-21 13:46:40 EDT
Are there firewall rules so copying zips from this new build.eclipse.org has QoS?  It seems rather slow to copy the content.
Comment 9 Denis Roy CLA 2010-09-21 13:57:26 EDT
The IP address hasn't changed, neither have the QoS rules.  From my home cable I can get 1.1MB/sec.  What kinds of speed are you getting?
Comment 10 Kim Moir CLA 2010-09-21 13:59:09 EDT
119 KB/s
Comment 11 Denis Roy CLA 2010-09-21 15:49:17 EDT
Kim, stop using an ISDN line.

Closing as fixed, since signing seems to be happy.  As for the download performance, I'm not sure what to say since I can't reproduce it.
Comment 12 David Williams CLA 2010-09-21 16:18:17 EDT
Thanks much, Denis, others .. I've added reference to bug 312787 which also mentions differences in VMs (and also mentions importance of reverse DNS entry, but ... I can't tell ... that might have been a Red Herring?)