Can you post the log here?

I suppose you have customization to include the discounted price in the Find index, and because you are using the old promotion system - it try to run get SP to get the available promotions to apply. Is that the case?

We can probably tell more when we see the log.

Hi!

Looks like this problem is gone now. Don't know why, but it looks ok for now. Lets just leave it!

Thanks Quan!

/Kristoffer

Regarding indexing,

Quan, any ideas on this one?

https://world.episerver.com/forum/developer-forum/EPiServer-Search/Thread-Container/2017/6/index-content-for-all-languages-for-episerver-commerce-in-find/

/Kristoffer

Unfortunately, No, I saw your support case but it works fine in our sample site. So it must be something specific for your site. When we have an environment which can reproduce the issue we can tell more.

Hi!

That is strange. So the same code with the same database runs fine in when you try it?
Well, hopefully you will find something soon.

/Kristoffer

No, I meant the indexing works well on our sample site (template + databases). I'm looking into your site. Let's hope I'm in lucky today

I hope so too! :-)

I tried with clean the index and re-index again and the other languages started to appear. I was cut off from VM (technical issues) before the indexing completes. If you didn't try that (clean the index), can you try it now? 

I have tried that several time. I start to think that it is related to my post about this:

https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2017/6/the-configuration-file-has-been-changed-by-another-program/

If the site crashes from time to time the indexing does to and maybe that is my it appears to only add Swedish products.

Yes, that makes senses because the master language (in your case, "sv") is always indexed first. If the indexing is stopped before it reaches other languages then that might happen.

The fact that editing a catalog content results in correct indexes across all languages is a proof that your index is OK and working well.

Perhaps you can try to run your indexing from a non-Azure server to see if it works?

@Quan, we are in production environment now and still the service stops after the Swedish content is indexed. It must be a crash of some kind because the job is in "running mode" forever and there is no errors in the task log. I will open the ticket again and maybe you can try and run the job from an Azure environment?

/Kristoffer

@Quan, we are in production environment now and still the service stops after the Swedish content is indexed. It must be a crash of some kind because the job is in "running mode" forever and there is no errors in the task log. I will open the ticket again and maybe you can try and run the job from an Azure environment?

Thanks!

/Kristoffer

One possible theory is that the memory went up (which is reasonable because the scheduled job has to load all contents in order to index them), to the point that the AutoHeal feature of Azure kicks in and restart the site. Can you try and watch the memory usage for that? 

How do I watch the memory usage in Azure?

Hmm, that is a really good guess! I mean there is try/catch around everything so if an object doesn't get indexed you will have an error message, but we don't get anything. The job just crashes which I guess indicates that something with the environment has happend.

I'm not an Azure expert but a system engineer in your hosting team might be able to help out? I'm using NewRelic (on some other sites, of course) and it's quite easy to monitoring the memory usage (and more generic, the life/health of the instance). I guess Azure have something similar?