Developer forum

Hi Adrian,

I've tried to reproduce what you describe, but on my configuration, with my data I simply cannot reproduce. Can I get you to describe a very simple setup on an empty wrap, where this behavior is reproduceable? I'm most likely doing something different then what you are experiencing, so the same data and steps would help a great deal.

BR

Martin

Hi Martin,

You will not be able to reproduce it on you local environment.

I have probelms reproducing it on the live environment.

The issue is somehow related to a caching of some sort. When a user first logs in, an information about the assortment is stored. Everything that is added later on, will not be updated on his assortment information. My guess is that the process responsible for updating the assortment information will never end its cycle resulting in outdated information.

In the case of regular projects where you have a just a bunch of users and usergroups and a few assortments, this will never happen.

Last night, after posting the message, I have looked in the cache.net folder and I have found a lot of XML files in the format GROUP_GROUP550.permissions.xml

Since the relation between Users and Products/Groups is stored in AssortmentPermissions table, I have assumed this is the place where the permissions are cached. Most of the files were not updated since february. I have deleted the files, run the Index and then rebuilt the assortments and the problem was solved. Now I see that all of the files have been updated and they are dated accordingly.

This is why I think it is related to a caching that is not overwritten. Probably the testing you guys did when you have created this update process could not reproduce this case because of its complexity. If you somehow manage to work on it, it might be an improvement for other cases as well.

Thank you,

Adrian

Hi Adrian,

The thing is, that the "things" related to assortments are mostly cached in the Cache. That means, in-memory caching.

If you're looking into the index-built-files, then it's probably something related to the indexing engine. Did it have some errors in the log? :)

Anyway, Im happy you get it fixed somehow.

BR

Martin

Hi Martin,

Sometimes, I agree it is memory based. That's why sometimes it works just by recycling the AppPool.

This time the information was more persistent than just memory, that's why I assumed there should be something in the database or on the filesystem that has not been updated or purged on Assortment rebuild.

We'll see if this is the solution next time I will get into the same problem. Anyway, there should be a more buil-in solution for solving this than me going in the backend and deleting files or running different services. It should be self-sustainable.

I will let you know if I run into more problems.

Thank you,
Adrian

Hi Adrian,

I agree. The index being rebuilt should be "manual maintainance-free". But it might contains bugs. :)

If you find a way to reproduce this behavior, please send the files and step to reproduce to our support - then we will fix it.

BR

Martin

Hi Martin,

it looks like the problem resurfaced after adding new products in the product Catalog.

The assortments for authenticated users is not updated after 4 days in which the Index was rebuilt afew times a day and the assortments were also rebuilt.

Somehow, the assortment permissions for authenticated users is persistent.

Adrian