Memcache, doc/help permission issues, Realtime, HELP!

Darin

1st Problem:
Installed memcache, and memcached, run as daemon, enabled in config, works. However attempting to run my startdaemons.sh ends in numerous fatal errors except ironically the memcache ends in DONE. Disabling the memcached in config to false allows the startdaemons.sh to function as normal starting my queue,twitter, etc daemons.

2nd Problem:
rewrite is on, and works throughout the site EXCEPT for the link /DOC/HELP which I end up with a forbidden error message when I try to access it. It works fine if I test overide with index.php?p=/doc/help

3rd Problem:
Realtime "addPlugin('Realtime');"plugin is active in my config file however I do now see the play/pause buttons like I do on Identi.ca. Looking at html source I do see the CSS file inserted but no other references.

Any help would be appreciated!

aric

You need to have meteor(or somthing like it) running for realtime. as for memcached, try it enabling it without daemons, and then telenet into memcached (telnet localhost 11211) then type "stats" use the site a bit and see if the memcache is growing. Then go back to the daemons, and enable/start one at a time to determine witch one is casuing a problem. (/scripts/getvaliddaemons will return the enabled ones) also I believe that the command to start daemons is scripts/queuedaemon now)

Darin

Aric thanks for the reply. I'm focusing on meteor and pulling hair at the end. I have meteor installed on a seperate IP, port 80 for subscriber port, I have add plug in for meteor in my config, I see all the buttons now, meteor is configured correctly as far as I can see with my tests, i'm able to connect and add messages etc, output is on port 80 via tcp.

When I hit my statusnet page, I see debug info on meteor, all looks fine, it joins the channel, perfect.

However when I post, it never sends the ADDMESSAGE through the same connection, nothing gets posted through so nothing is coming back on the page.

Any ideas on this one? Its odd that the browser will connect correctly and join the channel but then no post to it.

I'll troubleshoot the memcache as you suggested. Got rewrite issue handled.

aric

addPlugin('Meteor', array('webserver' => 'meteor.yourdomian.ca', 'webport' => 80));

make certain that you can telnet to meteor.yourdomian.ca 80 from the server itself and from you home machine. (the internet at large)

aric

also do you get errors in the logs when you start queuedaemon? its needed to push the notices from the db to meteor.

Darin

No errors. It starts fine.. Also launches my twitter connections which work fine. I have the correct config entry, I messed with it to see if output changes in the source of the html and it does, I have a port 80 under a subdomain of my main domain, and the controller is still under the standard 4671 port. I can connect from server and home and inject addmessages and see debug output.

You are saying the queuedaemon.php background process is the one which pulls new db items and sends them to meteor correct? If so, this is where my problem is. Any other tips on troubleshooting why this is not pulling and sending to meteor?

Appreciate all your help!

P.S. In the middle of all this, I upgraded to the final v9. But same problem. All else works great, new clean install too.

brionv

Darin, can we take a peek at the addPlugin line in your config for Meteor?

Here's what I've got on my net-accessible test site, using the default ports:

addPlugin('Meteor', array('webserver' => 'status.leuksman.com',
'channelbase' => $config['site']['nickname']));

(The channelbase is for setting two sites to use different channels, you can leave that out for a single site.)

Since you've switched the web port and are running on another IP, it sounds like you need to have at least:
addPlugin('Meteor', array('webserver' => '<your-meteor-hostname>',
'webport' => 80));

Iis meteor's control port listening on the same IP address/hostname that is listed for its web server? If not you may also have to add a 'controlserver' entry with the local IP/hostname.

If that doesn't clear it up it's probably wise to check the output & logging for the queue daemons. If it can't open the socket to the control port, it should throw an exception; this'll either end up in logging output or just throw a fatal error to the console the daemon was run from. It may also trigger a PHP warning, which could be in the StatusNet log file, syslog, or console depending on PHP & StatusNet's logging settings.

Darin

Yes my addplugin is setup correctly in my config. Its listening on the same IP with the default port (controller), I also added that just to make sure.

addPlugin('Meteor', array('webserver' => 'realtime.mydomain.net', 'webport' => 80,'controlserver' => 'realtime.mydoman.net','controlport' => 4671,'channelbase' => 'mychannel'));

I've gone through the debug, syslog, daemon, and a few others. No errors having anything to do with the queuedaemon. Would I do a search for queuedaemon or ?

All I have are:

DBQueueManager (main): No notices waiting; idling.
Mar 4 10:59:09 mydomain statusnet: [www.mydomain.net:queuedaemon.php:1870] Sleeping 10 seconds until next poll cycle...

Darin

Okay.. some success! No errors, but I killed all the queuedaemon instances and re executed startdaemons and success.

HOWEVER!

I still have this nasty scrolling 'Busy' icon attached to my mouse in Google Chrome when I'm on my site. It doesnt go away unless the cursor is inside a text box. I dont get this on identi.ca, same browser, etc. Any ideas on this? Something is not right.

aric

So its working minus those bugs?
@csarven has made some patches against meteor. those should clear up those problems. you can just download them from http://meteor2.identi.ca/meteor.js and um.. one other one from meteors /public-html folder. cant remeber right now, Ill come back

Darin

Aric thanks a bunch! Yes the meteor setup is working fine now. I thought I restarted the daemons over the last 24 hours of hair pulling but apparently I had not. All is great now less that update you mentioned, perfect I'll grab those and whatever else you post.

Once I get that knocked out and the firewall setup for the controller port, I'll move back to the memcache and see whats going on tonight.

Darin

Aric found the fix for Google Chrome endless busy mouse pointer, small adjustment in the stream.html thanks a ton. For anyone elses reference its located here:

http://code.google.com/p/meteorserver/source/diff?spec=svn66&r=66&format=side&path=/trunk/public_html/stream.html

aric

Sweet, glad its all working.

Darin

@brionv looks like memcached is a little weird on my setup. if I enable it, all is fine until I delete a notice. After that I only get the first page of notices on the main public timeline (before button disappears).

The more items I erase, the less items show up on the first page.

Just to verify, I have memcache on the web server front end machine enabled, disabled in my config on my backend mysql server.

brionv

@Darin I think that's actually a known problem with the public timeline when caching's on; I'll make a note to investigate that and get it cleaned up. I think it's not clearing the cached copy of the public timeline on deletion, which then messes up the paging.

In the meantime, when you make a new post it should clear up the public timeline.

Doesn't affect identi.ca much with the posting volume but it's going to hit smaller sites more often, so this is a good time to get it fixed! :)

Darin

Great, lmk when you have a fix for this and I'll test it.

brionv

This should do it, now on testing branch:

[testing cb471e0] Blow more timeline caches on notice delete. Fixes paging on public and profile timelines after deleting something from the first page.

Darin

Got it, looks good so far will keep you updated if not, thanks! I notice the pages actually sort correctly now. I remember random items repeating as well, this seems fixed.

aric

@brionv +1