Question AOP with Load balanced servers (EC2)

[Jonty]

Hi there,

I've purchased vBShout, and i'm keen to install it on my forums.

The trouble is, the forums are load balanced EC2 instances, i.e. multiple file systems.

This is fine for most of your plugins, as most dont write to the file system, but this one appears to.

The problem is with the AOP directory which is require to be set to write files to - what appear to be just timestamps in text files.

I found this thread, but I noticed in the code when I had a look, it mentioned database?

	if (!is_writable(DIR . '/dbtech/vbshout/aop/'))
		{
			// Fall back to database
			self::$fetched['error'] = $vbphrase['dbtech_vbshout_aop_error'];
			
			// Time now
			$mtime = TIMENOW;
		}

Does this mean the file system requirement has changed? Or will I need to modify the files still.

Thanks

 

[Fillip H.]

All the instances of /dbtech/vbshout/aop found in the class_core.php file will need to be changed, and the /dbtech/vbshout/clientscript/vbshout.js file also has references to the AOP file directly which will need to be changed as well.

Is there any way I can add this compatibility into the product natively, without disrupting functionality for other users?

 

[Jonty]

All the instances of /dbtech/vbshout/aop found in the class_core.php file will need to be changed, and the /dbtech/vbshout/clientscript/vbshout.js file also has references to the AOP file directly which will need to be changed as well.

Is there any way I can add this compatibility into the product natively, without disrupting functionality for other users?

Am I right in thinking all its doing is writing a single timestamp to each of the files? The way I intend to get around it, is making a php script to write them to/read from the database instead.

I'll happily share my solution if and when I get it working.

I suppose you could make a 'toggle' variable somewhere, to either use the database, or the filesystem.

 

[Fillip H.]

Yes, but writing to the database is not going to work. It will significantly reduce performance and will require large rewrites to the JS file as well, as the JS reads from the text file.

We won't be implementing a DB option for that reason, it would almost completely negate the point of the AOP feature.

 

[Jonty]

Yes, but writing to the database is not going to work. It will significantly reduce performance and will require large rewrites to the JS file as well, as the JS reads from the text file.

We won't be implementing a DB option for that reason, it would almost completely negate the point of the AOP feature.

Hm. Depends how the database is setup. If it was memcached etc, the performance difference would probably be negligible.

I guess i'd have to try it and see.

 

[Fillip H.]

I was more speaking in terms of how most of our customers have their systems set up - I'll keep it in mind whether we can offer both methods, we'll have to see how much trouble that would be.

I think it's fair to say the majority of our customers don't use load balanced systems, it's a shame the Shoutbox starts acting up on such systems D:

 

[Jonty]

I was more speaking in terms of how most of our customers have their systems set up - I'll keep it in mind whether we can offer both methods, we'll have to see how much trouble that would be.

I think it's fair to say the majority of our customers don't use load balanced systems, it's a shame the Shoutbox starts acting up on such systems D:

I've been thinking about this... why does the javascript not just cache the timestamp? Whats the reason behind it being stored server side.

If stored locally, it could be passed as a parameter with each query - as long as you sanitise the value, i.e. limit it to a certain time interval so no one can select 300 years worth of messages - I don't see why this couldn't be done.

Storing the timestamp in the database would surely be a safer way to go too. What would happen at the moment if two 'People' wrote to write to the file at the same time? In the database version, queries would just be queued up, file locks would just fail.

Checking the txt file is consuming file handles just as much as the database version would consume resources.

Maybe i've interpreted it wrong, but it makes more sense (to me at least), the database way.

I'll work on it tomorrow, but would love to know your thoughts.

 

[Fillip H.]

I've been thinking about this... why does the javascript not just cache the timestamp?

Because Javascript is client side

Whats the reason behind it being stored server side.

We need to be able to detect when there's a new shout, and there's no way to have a browser tell another browser when this has happened.

Storing the timestamp in the database would surely be a safer way to go too. What would happen at the moment if two 'People' wrote to write to the file at the same time? In the database version, queries would just be queued up, file locks would just fail.

This has never been an issue for us, since the files only contain the timestamp it takes hardly any ms at all to write to the file

Checking the txt file is consuming file handles just as much as the database version would consume resources.

But not as much as initialising either the full vB environment or opening the config file to read the DB params, opening a DB link, select a DB, query the time stamp (from a table that can be very big), close the link, then return the value

 

[Jonty]

Because Javascript is client side

We need to be able to detect when there's a new shout, and there's no way to have a browser tell another browser when this has happened.

This has never been an issue for us, since the files only contain the timestamp it takes hardly any ms at all to write to the file

But not as much as initialising either the full vB environment or opening the config file to read the DB params, opening a DB link, select a DB, query the time stamp (from a table that can be very big), close the link, then return the value

Hm. There are definately ways round this, but i'll explain in the morning lol.