Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325811

Summary:	signing process is excruciatingly slow
Product:	Community	Reporter:	David Williams <david_williams>
Component:	Servers	Assignee:	Eclipse Webmaster <webmaster>
Status:	RESOLVED FIXED	QA Contact:
Severity:	blocker
Priority:	P3	CC:	john.arthorne, kim.moir
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=312787
Whiteboard:

Description David Williams

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

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

2010-09-21 11:46:43 EDT

*** Bug 325870 has been marked as a duplicate of this bug. ***

Comment 3 Denis Roy

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

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

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

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

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

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

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

2010-09-21 13:59:09 EDT

119 KB/s

Comment 11 Denis Roy

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

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?)