I managed to fix this by exporting the database, dropping it in postgresql, re-creating it and then re-importing. Performance seems much better on the script too. Call times have halved!
From: [email protected] [mailto:[email protected]] On Behalf Of Anton Pritchard-Meaker Sent: 10 April 2013 15:17 To: [email protected] Subject: Re: [Spacewalk-list] API calls for new hosts This script works nicely for existing hosts, the problem only occurs when I subscribe a new host and run the script/call. As an example, an existing host with 36 updates available takes 4.7 seconds to get a result from Spacewalk whereas the new host below is taking 406. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Paul Robert Marino Sent: 10 April 2013 15:03 To: [email protected]<mailto:[email protected]> Subject: Re: [Spacewalk-list] API calls for new hosts It means your client timed out the connection. I assume this is Perl if so than you need to look at LWPs documentation to tune the time out parameter. -- Sent from my HP Pre3 ________________________________ On Apr 10, 2013 9:52 AM, Anton Pritchard-Meaker <[email protected]<mailto:[email protected]>> wrote: Not too sure why, but a fresh request has generated the following log entries, but still no output and a 500 timeout returned: Api logs: [2013-04-10 14:20:02,951] INFO - REQUESTED FROM: 192.168.131.146 CALL: system.listLatestUpgradablePackages(4267x7b6a0781772f903417626f29664317c0, 1000010137) CALLER: (******) TIME: 406.117 seconds Tomcat: 10-Apr-2013 14:20:02 org.apache.jk.core.MsgContext action WARNING: Error sending end packet java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) at java.net.SocketOutputStream.write(SocketOutputStream.java:153) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:538) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:679) 10-Apr-2013 14:20:02 org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Are there any other logs I could have a look at? From: Anton Pritchard-Meaker Sent: 09 April 2013 16:42 To: [email protected]<mailto:[email protected]> Subject: API calls for new hosts Hi, This one was happening in 1.8 and 1.9 on my RHEL5 based Spacewalk installation. I have a script to prepare update details for audit that works nicely with hosts already registered, but newly registered ones don’t work – returns a 500 timeout: my $systems = $client->call('system.searchByName', $session, $search); returns the name ok: [2013-04-09 16:23:52,714] INFO - REQUESTED FROM: 192.168.131.146 CALL: system.searchByName(4251x1ef1784c1d24abde4de1b183305f7458, *******) CALLER: (******) TIME: 0.351 seconds my $kernel = $client->call('system.getRunningKernel', $session, $system->{'id'}); returns the kernel ok: [2013-04-09 16:23:52,738] INFO - REQUESTED FROM: 192.168.131.146 CALL: system.getRunningKernel(4251x1ef1784c1d24abde4de1b183305f7458, 1000010137) CALLER: (******) TIME: 0.014 seconds The next call is my $packages = $client->call('system.listLatestUpgradablePackages', $session, $system->{'id'}); At this point I get a “500 read timeout”. All details are returning fine via the GUI. The script is here - http://hastebin.com/tesovipoki.pl Any suggestions would be great – I don’t get anything in the tomcat logs unfortunately. Cheers, Anton Pritchard-Meaker | Unix Engineer KIT digital | York | www.kitd.com<http://www.kitd.com/> | The Future of Television
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
