02-12-2012 08:24 PM
I'm getting to the point where I want to sign my WebWorks Playbook application for testing and for ultimately publishing it on AppWorld. I successfully requested and registered my code-signing keys, which went off without a hitch as per the manual.
However, as soon as I try to package + sign (either using Ripple or CLI) I get the following: Error: Server returned HTTP response code: 502 for URL: http://www.rim.net/Websigner/servlet/RDK-Waterloo
Of course this is really concerning, because, you know, I need to be able to sign my apps right?
Now, before you assume there's something wrong with my setup... I just walked up to my desk, re-ran the signing command, and it worked without a hitch. But then a few minutes later I tried to sign a package again and it died with the same 502 error.
502 is a remote-side problem anyway... Could the signing servers be overwhelmed from traffic? Is the load balancer falling over because it's not tuned too well?
Whatever is causing this error, is anybody else experiencing this? :-\ If so, how do you get around it?
Thanks
--Alex
Solved! Go to Solution.
02-14-2012 06:30 PM
Hi Alex,
Are you still seeing this regularly? There hasn't been any RDK server downtime this weekend as far as I am aware but will take a look through our logs. Also, just to confirm (if the issue still exists) sometimes it works and sometimes it does not, correct?
Erik Oros
BlackBerry Development Advisor
02-15-2012 02:07 PM - edited 02-15-2012 02:09 PM
Erik,
Thanks so much for your quick reply!
As it turns out, the problem was only happening for me at the time that I reported it here. On the 13th, when I signed my app for submission to AppWorld it went fine. Also, just now, when I attempted to sign another package, that went fine too.
Could it be that it was blowing chunks before due to the fact that my vendor account had not yet been approved? ![]()
Anyway, it seems to be working now for me.
EDIT: By the way, when it was failing for me, it was failing consistently over the course of many hours. Except that it successfully signed a package one time. Weird, huh?
02-15-2012 03:01 PM
Weird indeed.
The vendor account wouldn't be linked to your ability to sign (i.e. we have many non-vendors that sign applications all the time.)
As for what the cause was, I'm just not sure. If it does come up again let us know. If you could keep track of the time(s) that this happens as well, that should help narrow down our investigation but as mentioned, I'm not seeing any downtime over the weekend.
I guess we're chalking this one up to ghosts in the machine...
Erik Oros
BlackBerry Development Advisor
04-11-2012 01:44 PM
Hello,
This is the only thread I seen on this issue.
I get this issue regularly. It isn't too hard to reproduce either.
One moment you can package and sign your app no problem. Then try it again just a few minutes later and that error occurs.
What I find is, if my machine is downloading something and my internet connection is chugging away I get this error. If I stop all downloads, then I have no issues. To me is feels like some sort of timeout issue.
Mark
04-12-2012 12:36 AM
04-12-2012 12:04 PM
Hi there,
Unfortunately not much can be done. For security reasons, code signing requires a communication between the Signature Tool and RIM's servers. The communication itself is very small, but if the internet connection is bogged down by other things, a timeout/dropped connection would affect the abilityi of our servers to respond to the PC's request.
For tablet development, we do have Debug Tokens which require an internet connection to configure, but then you can get 30 days out of each one for testing purposes without requiring signing. There is no equivalent on smartphones though.
Erik Oros
BlackBerry Development Advisor
08-03-2012 06:25 PM
Having the same problem here. Not the internet connection as I've tried it on two connections which both work well for everything else.
08-06-2012 08:49 AM
Hi there,
Are you still seeing issues? There appear to be some errors in the logs that may have affected signing ability but looks to have been resolved as of Saturday afternoon.
08-06-2012 11:30 AM