Blank result page

[mangas]

I have a problem with the V6 Zoom Search

When I search something it gives a blank web page. 5.1 version works well.

output for results : http://labo.mangaman.net/search.php?zoom_query=glu

Can it be something with my host?

Thanks a lot

[David]

Are you sure your hosting company supports PHP? Do you already have other working PHP scripts on this web site?
Did you edit our script at all?
Did you try V5 of Zoom instead of V6?

Also as you are running Apache, there is a small chance it is this know Apache configuration issue.

[mangas]

Yes, my host supports php, and zoom search 5.1 works well on it. I have php 5.2.2. I'm using other php scripts such as Wordpress, Gallery 2 and other smaller php scripts.

I haven't edited anything in the zoom search script.

I've tried your script in the apache configuration thread to see if my host stopped the script and it stops at "allocated memory for 760000 integers." I know my host has a max execution time of 60 secs for scripts.

It's strange that it works well with 5.1 and not with v6.

[David]

If you would like to give us access to the site (e.g. FTP access to labo sub-domain) then we can have a deeper look at what has gone wrong.

But if the test script stopped at 760000 integers, then you do have low limits on the server. Either a very low RAM limit of about 4MB of RAM, or a execution time limit of well under 60sec. It should get to 2,000,000 (and needs to get to an even higer value if you have a large index).

[Ray]

I've tried your script in the apache configuration thread to see if my host stopped the script and it stops at "allocated memory for 760000 integers." I know my host has a max execution time of 60 secs for scripts.

It's strange that it works well with 5.1 and not with v6.

If the test script (which is very simple) is being prematurely terminated by your server, then the problem is independent of the version of Zoom being used.

There's a number of possible reasons why it worked when you tried it with V5.1. You might have indexed a smaller number of files, smaller sized files, or there was simply less settings enabled (V6 has more features). You might be able to configure V6 to behave in a similar stripped down fashion so that it will work, but it's much better to address the real cause of the problem. Chances are, when you try to index a bigger set of files (or enable more features) with V5, you will hit the same problem as well.

[BASE]

Testing Zoom Search v6 - No Joy!

First I downloaded the script not realizing that it was the free version. I thought it would be a time limited demo version, so I'm not sure if this could be causing the problem I am having, or not.

The log file shows that I am getting "file size limit exceeded", but the program finishes spidering the site I am testing it out on, and uploads the files to the server.

After upload, a visit to the search.php page, simply returns a blank page.

I have even tried "search.php?zoom_query=searchphrase" which is also returns a blank page.

The server is mine, and setup with multiple sites (shared hosting), but each site is sandboxed, and is basically setup as a virtual server.

PHP is 5.2 on RHEL running Apache 2.0.52 and MySQL 4.1.21

I downloaded the Apache test script which stopped at "allocated memory for 920000 integers".

The "memory_limit" in the php.ini file was set to 64M by defaut, and doubling this to 128M resulted in "allocated memory for 1845000 integers", and tripling it to 192M resulted in the script completing the loop ("allocated memory for 1995000 integers. End test loop").

However, the search.php script still resulted in a blank page, and increasing it to 500M was no help either.

According to the log, there were only 20 files indexed, and the largest ".zdat" file I have is zoom_wordmap.zdat at 52.9 KB (54,202 bytes).

I would like to know of any other suggestions, and how much memory is actually required to run this script?

This script appears to be fit the bill on what I was looking for, but it doesn't seem to work.

I should mention also that the results are the same in FF 3.05, and IE 7, both 32 and 64 bit versions.

[David]

If you would like to give us access to one of the sites (e.g. FTP access) then we can have a deeper look at what has gone wrong.

Did you also check the Apache RLimitMEM & RLimitCPU settings?

[BASE]

In my 9+ years of maintaining a server, on oaccasion I have had to make adjustments to the php.ini file, but I have never had to make any adjustments to the settings you mention (RLimitMEM & RLimitCPU), in fact I have never come across this before at all.

According to Apache.org: http://httpd.apache.org/docs/2.2/mod/core.html

RLimitCPU Directive
Description: Limits the CPU consumption of processes launched by Apache children
Syntax: RLimitCPU seconds|max [seconds|max]
Default: Unset; uses operating system defaults
Context: server config, virtual host, directory, .htaccess
Override: All
Status: Core
Module: core

RLimitMEM Directive
Description: Limits the memory consumption of processes launched by Apache children
Syntax: RLimitMEM bytes|max [bytes|max]
Default: Unset; uses operating system defaults
Context: server config, virtual host, directory, .htaccess
Override: All
Status: Core
Module: core

Neither are enabled by default, and can be overidden via .htaccess. I have looked through the Apache .conf files, and the Virtual host .conf files, and they are not set in my configuration.

I would be happy to let you take a look if you think it might help.

*** Email Sent 13:13 GMT -8***

[David]

Blank page solved

Many shared hosting companies are using RLimitMEM & RLimitCPU to stop large script running on their servers. (Mostly the cheap hosting companies with overloaded servers). But as it turns out this is was not the problem in this case.

At first I thought it was a server side redirection problem. Check out this strange wget trace.

 
C:\>wget http://www.calilighting.com/_temp/search.01/search.ph
p
--11:31:19-- http://www.calilighting.com:80/_temp/search.01/search.php
=> `search.php'
Connecting to www.calilighting.com:80... connected!
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.calilighting.com/_temp/search.01/search.php [following]
http://www.calilighting.com/_temp/search.01/search.php: Redirection to itself.
http://www.calilighting.com/_temp/search.01/search.php

Note the message. Redirection to itself.

So I spent some time looking at this. But this also turns out not to be the problem. But it is still strange.

The actual real problem was that you are using a slightly old version of the script, that had a parsing issue with some releases of PHP. And then due to some server side configuration setting the error message is not be returned to the browser.

So you should have seen an error message and not a blank page. But this was blocked on your server.

Updating to the V6.0.1002 PHP script corrected the parsing error and fixed the problem. You can see the working search function here,
http://www.calilighting.com/_temp/search.01/search.php

Thanks for making FTP access available. It might have taken weeks to work this out without access to the site.

[BASE]

Not a problem, I know that it is usually much easier to troubleshoot in person

The redirect to itself may have something to do with a mod rewrite rule that I have setup.

FYi: >>
The "slightly older version" of the script that you said I was using, came directly from the download link on this site, just yesterday.

I downloaded the script installed, configured, ran, and the rest is history.

Also, the script is also running with the php.ini file back at default settings (memory_limit = 64M)
<<

So how do I download the revised version? Has the link been updated?

Thanks!!!

[David]

Yes V6.0.1002 is the current release, as of today in any case, and we are aiming not to need to do any new releases over Christamas, fingers crossed.