JS calls interference

[molsim]

while is seems that I fixed almost all the problem, there is one problem that persist and I have currently no idea how to solve it.

Every browse_varinat page fires two js calls to get_sequence_table_data - one for curated sequences and one for automatically extracted sequences.

Very often one of the calls is returned with 500 error, and the data is not loaded. Is seems that there is some kind of interference between this calls.

When I try to trace where the execution stops inside results = HistoneSearch(parameters)

[molsim]

Repalced ajax with ajaxq 6911af2a5e0163e4570e0858c40b0bad5504bac8. So the calls are sequential. Let's see if this helps in NCBI setting. Locally, this does not solve the problem 100% times. On production the proxy might help though.

[neksa]

Sounds more like thread safety issue with the database calls on the server side. It could happen when the same database connection is being used in two or more threads simultaneously.

Try reloading browse_variant page repeatedly in the browser (with refresh=1), while testing the website in another browser window.

[molsim]

How can you allow database to be used in multiple threads simultaneously?

[molsim]

Ok, with ajaxq, the error now seems to be very rare at least on django dev server. Howerver, I still do not understand what's causing it.

[edraizen]

Yes that is very strange. It might be due to race condition for the same url. One workaround would be to create two different django urls for curated sequences and for automatically extracted sequences.

I'll try that now.

Cheers, Eli

On Monday, January 4, 2016, Alexey Shaytan notifications@github.com wrote:

Ok, with ajaxq, the error now seems to be very rare. Howerver, I still do not understand what's causing it.

— Reply to this email directly or view it on GitHub https://github.com/edraizen/HistoneDB/issues/157#issuecomment-168757558.

[neksa]

The easiest way to check if it's thread safety / race condition issue is to disable threads. Yes, it will consume more memory, but will result in a more stable behavior I think.

Try changing method="threaded" to method="prefork" in runfastcgi() call in index.fcgi

[molsim]

Thanks, Alex! The problem is clearly in threads: /manage.py runserver --nothreading solves the problem. hope that refork will solve it too.

[neksa]

Great!

note the typo: prefork

On Jan 4, 2016, at 7:16 PM, Alexey Shaytan notifications@github.com wrote:

Thanks, Alex! The problem is clearly in threads: /manage.py runserver --nothreading solves the problem. hope that refork will solve it too.

— Reply to this email directly or view it on GitHub https://github.com/edraizen/HistoneDB/issues/157#issuecomment-168851608.