Forum Activity for @brian

brian
@brian
11/17/15 08:37:49AM
10,149 posts

Marketplace updates


Installation and Configuration

DannyA:
With acp, you can't update your modules if your core is behind. So I recently updated the core from 5.2.37 to 5.2.41. It took us a while, and we didn't get to update the other modules before 5.3 beta came out. I don't want to install the beta yet. How can I update the other modules without updating the core to a beta release?

You can update to new module releases without being on the beta core - just make sure the BETA channel is NOT active in the Marketplace -> Tools -> Release channels section, or you'll always be prompted to update to the beta core first.
brian
@brian
11/17/15 08:36:20AM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

I believe this should be better now in 5.3.0b5 - another JR customer had the same issue as you updating to 5.3.0b4 (they were still using the "old" site builder"). Update to 5.3.0b5 and let me know if that works better.

Root cause here was that the query builder could construct a portion of the query that contains an "OR" conditional, but was missing some outer parenthesis, which was resulting in what is known as a "cartesian product":

https://en.wikipedia.org/wiki/Cartesian_product

This basically made the number of results coming back be HUGE, so ended up running into the memory limit.

Let me know if that helps.
brian
@brian
11/16/15 06:41:14PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

soaringeagle:
ok everytime i enable b4 it currupts my db and i gotta restore it

There's no way the core upgrade is going to "corrupt" your DB - if it is causing actual data corruption, something else is going on at the server level (which seems to be a recurring issue with your server lately).
brian
@brian
11/16/15 05:49:05PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

soaringeagle:
corection
argh
testing the highest rated pagination after switching back to b4
the page wont load

If it works with b3, but not b4, then there has to be some difference that is causing it. Did you see my response above about getting a dump of your DB? I really could use that to do some testing to try and see what's going on.

Edit: If you can, contact me at support [at] jamroom [dot] net with your server login and I can use mysqldump to grab it.

Thanks!
updated by @brian: 11/16/15 05:51:24PM
brian
@brian
11/16/15 05:10:33PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

Just delete the existing symlink and create a new one to the version you want:

cd modules
rm jrCore
ln -s jrCore-release-5.3.0b3 jrCore
brian
@brian
11/16/15 04:51:51PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

soaringeagle:
as a test, can you tell me how to edit out that change
or would you like access to my server and test it yourself
this is kinda an emergency as much of my sites not working now

I apologize but I am not in my office and am actually on my wife's laptop, so I don't have access to anything here - you'll need to roll back.
brian
@brian
11/16/15 04:51:11PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

soaringeagle:
i just rebooted the server
tmp is only 6% used
i know it worked fine till the core update

i see
- Change: "_item_id" included if not specified in return_keys parameter to jrCore_db_search_items()

so your saying this is run at the end of th search items and the change _item_id included if not in return key..

it seems likely this is the cause..no?

That's not related. In a jrCore_db_search_items() call you can specify the "return_keys" that you want - this lets you get a subset of keys from the item instead of ALL the item keys. This is used in a few places in JR, but it's not related to your query issue. What this change did is just make it if you do NOT specify "_item_id" in your return_keys array, it is added for you (this is needed by event listeners and it was easy to forget to ask for it, so it is automatic).

The only REAL changes that I believe could have affected you were that some queries have some additional JOIN conditions now (this fixed the pagination issue you reported) - but that's not a problem here because we are already PAST that portion of the search items call - you're getting hung up on a query that it should not be getting hung up on.

Not sure what to recommend to you - roll back to 5.3.0b3 if it was working, or earlier if you can.

If you get a chance, send an email to support [at] jamroom [dot] net with a place where I can download a DB dump of your system (if that is OK with you) - I will load it up here tomorrow on my dev server and put it through it's paces to see if it is a DS issue or something else.

Thanks!
brian
@brian
11/16/15 04:37:29PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

I should add as well - both of those queries are in the "sorting results" stage - that means they are using a temp table - make sure you have enough temp space on your server - if you run out of temp space then those queries will just hang.

Note that there have been no changes in that function for quite some time - it's the same in JR 5.2.4x and earlier.
brian
@brian
11/16/15 04:33:22PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

soaringeagle:
yup trying to access the shop again
| 10771 | greentec_jam | localhost | greentec_jam | Query | 36 | Sorting result | SELECT `_item_id` AS i,`key` AS k,`index` AS x,`value` AS v FROM jr_jrgallery_item_key WHERE `_item_ | 0.000 |
| 10854 | greentec_jam | localhost | greentec_jam | Query | 10 | Sorting result | SELECT `_item_id` AS i,`key` AS k,`index` AS x,`value` AS v FROM jr_jrgallery_item_key WHERE `_item_ | 0.000 |
+-------+-----

These are from the jrCore_db_get_multiple_items() function (called at the end of jrCore_db_search_items()) - these should NEVER take this long to run - something is messed up here if you're seeing these queries taking 36 seconds. These are "straight up" queries - no joins and WHERE condition only uses primary key. Even on a large datastore (20+ million items) these queries will take less than 100 milliseconds to run.
brian
@brian
11/16/15 04:31:21PM
10,149 posts

Jamroom 5.3 Beta Kickoff
Announcements

soaringeagle:
| 10209 | greentec_jam | localhost | greentec_jam | Query | 1 | statistics | SELECT `_item_id` AS i,`key` AS k,`index` AS x,`value` AS v FROM jr_jrgallery_item_key WHERE `_item_ | 0.000 |

this seems to be whats holding it up still investigating

That's only been running for 1 second - that should not be the issue. I'm surprised it is taking a second though. Note that we don't develop on MariaDB - just an FYI as there certainly could be cases where JR performs much worse on MariaDB than MySQL, and vice versa.
  312