"500 read timeout on line 188" XML-RPC error

View: New views
5 Messages — Rating Filter:   Alert me  

"500 read timeout on line 188" XML-RPC error

by John D-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I'm unable to get XML-RPC connections going on my setup. Using
bz_webservice_demo.pl, pointing to the uri http://my.bugzillainstall.com/xmlrpc.cgi,
I get

500 read timeout at bz_webservice_demo.pl line 188

whereas pointing to the landfill demo install goes OK. This appears to
be the line that makes the call asking for version information.

Using:
Bugzilla 3.4.2
IIS 6
ActiveState Perl
SOAP::Lite 0.710.08

The Bugzilla installation is one of a few websites hosted on this
machine, differentiated by host header. A check of the IIS log for
this website shows that the http request of xml content was received,
but gave a response code of 502.

Is there some configuration I might be missing? Are there other error
logs I could be checking?

Any insight is greatly appreciated. Cheers!
_______________________________________________
support-bugzilla mailing list
support-bugzilla@...
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-bugzilla@... in the To: field when you reply.

Re: "500 read timeout on line 188" XML-RPC error

by Max Kanat-Alexander :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/10/2009 01:00 AM, John D wrote:
> I'm unable to get XML-RPC connections going on my setup. Using
> bz_webservice_demo.pl, pointing to the uri http://my.bugzillainstall.com/xmlrpc.cgi,
> I get
>
> 500 read timeout at bz_webservice_demo.pl line 188

        My suspicion is that the IP address that my.bugzillainstall.com points
to cannot be routed to from inside your firewall.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
_______________________________________________
support-bugzilla mailing list
support-bugzilla@...
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-bugzilla@... in the To: field when you reply.

Parent Message unknown Re: "500 read timeout on line 188" XML-RPC error

by Cheetah-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Nov 19, 6:02 pm, Max Kanat-Alexander <mka...@...> wrote:

> On 11/10/2009 01:00 AM, John D wrote:
>
> > I'm unable to get XML-RPC connections going on my setup. Using
> > bz_webservice_demo.pl, pointing to the urihttp://my.bugzillainstall.com/xmlrpc.cgi,
> > I get
>
> > 500 readtimeoutat bz_webservice_demo.pl line 188
>
>         My suspicion is that the IP address that my.bugzillainstall.com points
> to cannot be routed to from inside your firewall.

I'm seeing this same kind of error on my setup, with any XML-RPC
client I care to try, including telnet and careful use of a text
editor to craft a request by hand.  No matter what I send xmlrpc.cgi,
as long as I have a Content-Length header, xmlrpc.cgi never sends me
back a single byte.  Even sending this gets no response:

POST /bugzilla/xmlrpc.cgi HTTP/1.1
Content-Type: text/plain
User-Agent: XML-RPC.NET
Host: softwareserver
Content-Length: 3

bob

When in this non-responsive state, looking at a stack trace for the
perl.exe on the server (using process explorer), it looks like it's
still waiting for more data from the client, as the stack trace has
several Perl...read... methods listed near the top.

I'm using bugzilla 3.4.4 with activeperl 5.8.8 on vista with iis7.
I'd previously been using 3.2.2 when I first saw this, and had hoped
that upgrading bugzilla and the related perl modules would help, but
no such luck :(
_______________________________________________
support-bugzilla mailing list
support-bugzilla@...
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-bugzilla@... in the To: field when you reply.

Re: "500 read timeout on line 188" XML-RPC error

by Cheetah-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Dec 9, 6:01 pm, Cheetah <fast...@...> wrote:
> I'm using bugzilla 3.4.4 with activeperl 5.8.8 on vista with iis7.
> I'd previously been using 3.2.2 when I first saw this, and had hoped
> that upgrading bugzilla and the related perl modules would help, but
> no such luck :(

FWIW, I just purged perl from the system and reinstalled the latest
ActivePerl 5.10.1, and it's still doing the same thing.
_______________________________________________
support-bugzilla mailing list
support-bugzilla@...
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-bugzilla@... in the To: field when you reply.

Re: "500 read timeout on line 188" XML-RPC error

by Cheetah-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Dec 10, 1:43 pm, Cheetah <fast...@...> wrote:
> On Dec 9, 6:01 pm, Cheetah <fast...@...> wrote:
>
> > I'm using bugzilla 3.4.4 with activeperl 5.8.8 on vista with iis7.
> > I'd previously been using 3.2.2 when I first saw this, and had hoped
> > that upgrading bugzilla and the related perl modules would help, but
> > no such luck :(
>
> FWIW, I just purged perl from the system and reinstalled the latest
> ActivePerl 5.10.1, and it's still doing the same thing.

More debugging: using PerlEx30.dll instead of perl.exe seems to make
xmlrpc.cgi work partially (*), but break everything else.  It seems
that the fact that PerlEx does the BEGIN block processing before
requests come in prevents all the normal CGI scripts from seeing their
CGI arguments :(

(*) xmlrpc.cgi will do queries, and reports success creating bugs, but
the bugs don't seem to be fully created.  xmlrpc.cgi can see the bugs,
but the normal web pages can't.  Perhaps database transactions aren't
getting committed due to how PerlEx works?  After restarting IIS,
xmlrpc.cgi can't see the bugs either, which points towards the
transaction thing too.
_______________________________________________
support-bugzilla mailing list
support-bugzilla@...
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-bugzilla@... in the To: field when you reply.