Hi Michael
Are you still experiencing this issue? If so you can report this as a developer support ticket: http://world.episerver.com/support/
David
Hi Guys,
Any updates on this? A few developers here are also experiencing the same issue.
The remote server returned an error: (401) Unauthorized
Old licenses work fine on the same solution. I can also verify that we are using the private find serviceUrl
Thanks
Paul
Hi
For anyone stumbling upon this post there is an issue at Eiserver. I reported it and received the following
"We are currently having problems with one of our dev clusters. Some old indices are also experiencing slow responses. Our Hosted services department are working on it."
Thanks
Paul
Hi
Any update on this? I'm experiencing the same issue with dev indices I created today.
Lars
I've also just run up against this today and would be interested in updates ...
I'm having the same problem here. I've tried with several newly-created indexes. Interestingly, my coworker is not having the same issue (he is able to create and use a new index without problems).
Hi Guys,
A number of developers here are also having the same issues with devloper indexes.
Able to create no problem but getting a 401 auth error.
Last time we raised it with EPi and it got resolved.
Paul
Hi, I can confirm that Operations are aware and working on resolving this. Sorry for the inconvenience caused!
Is there a place we can keep an eye on the progress on this issue and when the issue has been resolved?
This appears to be fixed, at least for me. I just created a fresh index, and I'm no longer getting a 401.
Still not working. Have we heard anything from Episerver about this issue?
This is getting old fast.
Same problem here. Just created a new dev index but gets 401. :(
/ Henric
A question for you that have a dev-index thats working.
When you create a new page, it will get indexed to Find. I can check the content in Find UI.
But after I do some changes to the page, the change doesn't get indexed. I can even delete the page from CMS, but the page will still exist in Find index. It will only get removed from the index if I clear the whole index.
Anyone else who got that problem recently?
/ Henric
We reported the same problem yesterday and no answer from support so far.
There should be a status indicator for the developer indexes on the https://status.episerver.com/ page. Developer indexes are mission critical for Epi partners.
New indexes are not working yet. Please try to prioritize it and let us know what should we do? Is there any approximate time to fix it? This is very criticle during development and we are now stuck due to this issue.
It's the indexes we set up in https://find.episerver.com/. I see that they are called demo indexes but we are using them for development of new Epi sites.
Are there other developer indexes that should be used instead?
They are not intended for development use. You can contact Episerver and order developer indexes instead, but please note that you also need a CMS or DXC Service license too. One developer index is included in DXC Service.
I think from what I have experienced where I work is that you get an index for Integration, Pre Production and Production. Am assuming the demo indexes were for local development when developing features. Is the index you are talking about for local developing or for integration?
Local developer index, so not the ones that is included for every environment. But since you have DXC-S you should be eligible for one developer index as well. This is a change Episerver implemented last year, I think. One would hope they communicated this clearly to everyone.
Not sure if you/we are breaking any rules by using the demo index though.
I am trying to explore Quicksilver Commerce B2B solution , so for that i have created a developer index for it. But due to this issue i am not able to see the site.
Can anyone provide quick workarounds?
Any updates on this? Trying to create developr index today, but when I try to reindex my site locally I get a 401 Unauthorized error.
As of now yet to get a reply from the support team regarding the tentative time for the fix of this issue. We are facing this issue from couple of days.
If you want better SLA you need to order developer indexes. Indexes created at find.episerver.com are just 30-days demo indexes. Please don't shoot the messenger :)
We are working on the issue, and it should be possible to create new indices during the day.
We're having this problem with 90 day Partner Developer (not demo) indicies. It's very frustrating - we're currently having to pass one working index (created before this bug hit) between five developers and two test environments, wiping it and reindexing each time we need to test a different dataset.
Please keep us posted as to when this is fixed. I'd also appreciate it if Developer Find was on status.episerver.com, as it seems to have problems quite frequently.
@Alex are you sure those are developer indexes? I'm pretty sure a developer index doesn't have a 90-day limit. Indexes created at find.episerver.com used to be developer indexes and valid for 90 days. But last year those were changed to demo indexes with a 30-day limit instead. You have to pay for a developer index, i.e. nothing you can create yourself.
A developer index is basically the same as a production index, hence status.episerver.com will also apply for those. Demo indexes does not have the same SLA and is not shown on status.episerver.com.
I know this is very confusing. It's the same for everyone. I wish Episerver would have communicated this BEFORE changing the developer indexes to demo ones.
We're an EPiServer Partner - we create them by logging into find.episerver.com, Clicking on My Services, then hitting a big button labelled "Create Developer Service", and they have a listed index type of "Developer Service". I'm fairly sure the life is 90 days and not 30, although I can't see this written down anywhere.
Those are demo indexes. They have forgotten to change all the labels. The confirmation email still says 'developer index' too. It clearly states on the home page though that these are demo indexes. As I said - very confusing.
A demo index has the following limitations:
You forgot one:
Those limitations sound right (I've certainly noticed the item limit being hit when it wasn't previously), but I'm fairly sure our licenses last longer than 30 days. Looking at the issue date and expiry of our last developer license in test, it was issued on 03/01/2018 and expired on 28/02/2018 - a rather arbitrary sounding 56 days.
When was the change made last year? I must have missed the communications.
He he (slow clap)
Everyone missed it. You're not alone. Hopefully there will be some official information communicated soon.
You should now be able to create new indices. Don't try to use the once you created with 401:s. Delete those, and create new once instead.
Sorry for all the trouble.
@Johan We have also queried the Developer index and have just been told that they are not included in the DXC and we have to order one. This seems like very mixed messaging. If that's the case I think the demo ones need to be treated with a higher priority as they seem to be used for developing against still.
@Jonas Thanks for the update
Just now i have created a demo index/developer service : I am getting the following error
{"status":403,"error":"Your key is not authorized to access (GET) '/'"}
You are not allowed to do a get on the index {url}/{privatekey}/{indexname}, that's by design. You can add /_search at the end to verify the index.
Can we get some clarification on what these "demo" indexes are suppoesd to be used for?
We've been using them as developer indexes - one for each dev's local environment for each project - and I'm reasonably sure this was what we were taught to do during training. If the "demo index" is not what we're supposed to use for local development, that means we'd need to use whatever the "developer index" is that is provided by DXC. Is only one of those provided? How does that work for partners that have multiple developers working on multiple projects?
Adding to this confustion, I see that some of the pages refer to these "demo indexes" as a "developer index." This thread has made it pretty clear that I'm not the only one confused here. The documentation (and Find website pages) need to be updated to reflect how a developer should set up their local environment.
I've had quite a lot of intermittent 401 and 503 errors recently, which really sucks because the application doesn't even start anymore. If you have the same you could give one of these workarounds a try https://www.brianweet.com/2018/03/20/unstable-episerver-find-developer-indexes.html
At least it allowed me to continue developing. We'll see what happens in time, let's hope the indexes will be as stable as they were before.
I have created new index and tried to index all items but somehow it only indexes ecommerce content and not CMS. I have updated same index in Mediachase.Search.config and Web.config but not able to find real cause. I have pages and blocks which i dont see in Find index list. Anyone here who is facing similar issues?
@Sameer I suggest you to create a separate thread for that issue, that is not related to the issues discussed here.
Seems like finally resolve:
https://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=COM-6785
Like others have mentioned, we have also been instructed to use demo indexes (formerly know as developer indexes, check web archive for instance) from the find portal by official EPiServer trainers, both cms and commerce trainers. Now it appears that EPiServer do not wan't us to do that anymore and instead wants us to buy actual indexes, which they call developer indexes now with a monthly fee associated.
This is not a good way of handling it IMHO, some of the projects we have are quite large and have 50+ developers on the project, so the actual developer indexes end up costing the clients a huge amount of money. An example client: The actual production indexes cost them around €1200 per month for medium size indexes for the environments they have, but if all developers would be required to buy indexes, it would cost them €10.000 per month just for developers being able to use EPiServer Find during development. That is insane!
Imagine Microsoft or Amazon charging developers for using their cloud services for development or said that "development/demo" versions would be down randomly, no guarantees? This would never ever fly, nobody would use their services. And this is exactly why there is free tiers for pretty much everything, EPiServer shold do the same.
With the current setup and the massive issues currently it is getting harder and harder to sell EPiServer Find to our clients, problem is there are pretty much no alternatives that are solid enough, and it is required for certain features in EPiServer. EPiServer needs to come out and make an official statement regarding how they wan't us to develop with EPiServer Find.
[Edit]
@Thomas: I agree.
@Aria: this was my response to you while Thomas was writing his 😉
I don’t think so. The fix only enables you to start Epi Commerce with a broken/unavailable Find index.
So far I haven’t heard any plans for improving the availability/SLA for the «demo indexes» since they are officially no longer intended for development use - which is a big problem for developers working on new features that require setting up temporary and separate self-serviced development indexes.
@Morten can you point me to the "official" statement regarding the indexes?
@Thomas: No, I misused the term “official statement”. I am referring to Johan Petterson’s responses to my previous comment in this thread, which seemed to represent Episerver’s view on the matter.
First of all, I'm very sorry for the confusion caused and the issues that has been plaguing the demo index clusters.
I'll reiterate some things already said previously in the thread but here goes;
Last summer we intended to clarify the intended use of the demo indices by renaming them. The reduction to 30 days happened recently to reduce the number of concurrent indices on those clusters, in order to give better performance to those indices that remain.
Developer indices are available for purchase and can be use concurrently by several developers as long as different SiteIDs are used and the scheduled indexing job isn't used (this is something we will work out to allow for this kind of use).
All DXC-S packages come with a developer index (apart from the integration, preprod, and prod indices already included) since September 13th last year.
All feedback around how we can make this work in the long run is most appreciated, as we need to find a solution that allows You to develop with a stable service, and at the same time not be increasing the development cost astronomically. I would appreciate if you could try out the "multi-dev-approach" to the developer indices and let me know what's missing to make it work fluently.
Yes, I completely agree about demo index, is just to see how it works (as the name express) and unfortunately if you really need developer episerver find the license, the only option is to purchase one! Some MVP are discussing this with Episerver. I think developer license should be free with SLA like DXC Integration environment!
@Joakim How do we handle the case when the client doesn't use DXC-S nor have a CMS license yet? We were told that we're not allowed to purchase developer indexes without a CMS license.
@Joakim,
that is indeed interesting because if understand you correctly in a case of 50 developer team we would need to buy just 1 developer index and "just" ensure that siteids are different among developers?
So
developer 1 has his own local database and uses a common developer index and names his site MySite1
developer 2 has his own local database and uses a common developer index and names his site MySite2
And this would just work (outside the scheduled job) ?
Because that would help a lot.
Can you clarify?
@Thomas I can clarify that this setup is working. We're even doing it in production. An Episerver instance can have multiple websites and they're all sharing the same index. When searching, hits are filtered on SiteID.
@Johan I know about that part, we use it ourselves for some large clients with multisite setups and it works great.
It was more of a clarification thing that in the scenario I mentioned it was exactly one index that is needed with developers each having their own development environment and local database, meaning content ids don't match, and it would still work if the siteids are different and that it is the correct way to do it license wise.
This is a big deal for a lot of our clients, because money wise there is a huge difference between having to buy 1 developer index that all developers can use on a project and buying individual indexes for each developer.
The document ID in Find is composed by both site ID and content ID. So even if you have content with the same ID, they shouldn't match. I'm pretty sure this is true. I ran into this issue when using same index for two different website for the same client. Then I had to manually add the site ID to the document ID.
Interesting, so a to-be-customer that is developing a solution before buying the product?
As covered upthread, this wasn't done very thoroughly. Here's what I see when I log into find.episerver.com and click on My Services:
Those Developer Services are apparently Demo Services, and the Add Developer Service button adds another Demo Service. I can be forgiven for not realising the goalposts had shifted, I think! I also don't recall seeing these changes announced on the homepage or via an email - do you have a link to any official announcement from last summer?
One last check - are we free to keep developing with demo licenses, provided we can live with the inconvenience, or are we obliged to purchase developer licenses for this purpose under the T&Cs?
No obligations, and we hope the services will work smoother in general after our backend updates that are coming within short.
An official statement (apart from the find.episerver.com information) was issued in the summer, as we were waiting until the DXC-S inclusion was sorted, which was finalised in September. My mistake and I apologise for that.
@Joakim
Do you have any updates/timeline for running the scheduled job as well?
Are there still issues with created demo indexes?
if i use the appsetting episerver:findcommerce.IgnoreWebExceptionOnInitialization= true then my application starts but without it doesnt start.
its this problem: https://www.brianweet.com/2018/03/20/unstable-episerver-find-developer-indexes.html
[WebException: The remote server returned an error: (503) Server Unavailable.] System.Net.HttpWebRequest.GetResponse() +1686 EPiServer.Find.Connection.JsonRequest.GetResponseStream() +249 EPiServer.Find.Api.Command.GetResponse(IJsonRequest request) +90 [ServiceException: The remote server returned an error: (503) Server Unavailable. ProcessClusterEventTimeoutException[failed to process cluster event (put-mapping [NestedDummyObject$$nested]) within 30s]] EPiServer.Find.Api.Command.GetResponse(IJsonRequest request) +669 EPiServer.Find.Api.PutMappingCommand.Execute() +213 EPiServer.Find.ClientConventions.NestedConventions.AddNestedType(Type declaringType, String name) +464 System.Collections.Generic.List`1.ForEach(Action`1 action) +100 EPiServer.Find.Commerce.CatalogContentClientConventions.ApplyNestedConventions(NestedConventions nestedConventions) +298 EPiServer.Find.Commerce.CatalogContentClientConventions.ApplyConventions(IClientConventions clientConventions) +181 EPiServer.Find.Commerce.FindCommerceInitializationModule.Initialize(InitializationEngine context) +182 [ApplicationException: Could not apply catalog content conventions. The content indexed during this session will not contain important additional fields and searches might work incorrectly, until the site restarts and the conventions are applied successfully. We recommend to fix the following exception, but if you are certain this exception can be safely ignored, add 'episerver:findcommerce.IgnoreWebExceptionOnInitialization' key with value = true to appSettings.] EPiServer.Find.Commerce.FindCommerceInitializationModule.HandleInitializationException(Exception exception, Boolean ignoreInitializationError) +175 EPiServer.Find.Commerce.FindCommerceInitializationModule.Initialize(InitializationEngine context) +645 EPiServer.Framework.Initialization.Internal.ModuleNode.Execute(Action a, String key) +58 EPiServer.Framework.Initialization.Internal.ModuleNode.Initialize(InitializationEngine context) +123 EPiServer.Framework.Initialization.InitializationEngine.InitializeModules() +248 [InitializationException: Initialize action failed for Initialize on class EPiServer.Find.Commerce.FindCommerceInitializationModule, EPiServer.Find.Commerce, Version=11.0.1.0, Culture=neutral, PublicKeyToken=8fe83dea738b45b7] EPiServer.Framework.Initialization.InitializationEngine.InitializeModules() +774 EPiServer.Framework.Initialization.InitializationEngine.ExecuteTransition(Boolean continueTransitions) +194 EPiServer.Framework.Initialization.InitializationModule.EngineExecute(HostType hostType, Action`1 engineAction) +876 EPiServer.Framework.Initialization.InitializationModule.FrameworkInitialization(HostType hostType) +225 EPiServer.Global..ctor() +42 Hyva.Web.EPiServerApplication..ctor() +37 ASP.global_asax..ctor() in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fddfb9a7\f5977155\App_global.asax.0.cs:0 [TargetInvocationException: Exception has been thrown by the target of an invocation.] System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) +0 System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) +139 System.Activator.CreateInstance(Type type, Boolean nonPublic) +105 System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark) +1431 System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) +184 System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture) +27 System.Web.HttpRuntime.CreateNonPublicInstance(Type type, Object[] args) +79 System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +262 System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +341 [HttpException (0x80004005): Exception has been thrown by the target of an invocation.] System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +523 System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +107 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +688
Yes, we are also getting similar error:
[WebException: The remote server returned an error: (401) Unauthorized.]
System.Net.HttpWebRequest.GetResponse() +1399
EPiServer.Find.Connection.JsonRequest.GetResponseStream() +161
EPiServer.Find.Api.Command.GetResponse(IJsonRequest request) +58
Hi Vishal and Sameer,
The developer clusters are currently being updated, therefore there may be some service disruptions affecting you. Estimated time left is about one hour where your indices may be affected. We're sorry for the inconvenience this is causing you!
Thanks,
Joakim
@Brian Weeteling Sorry for the late response, the scheduled job feature is at the top of the list after we have gotten our new infrastructure updates in place, so as soon as possible. Unfortunately it's hard for me to give a detailed time estimate, but I will update you when we are getting closer!
Thanks,
Joakim
thanks mate... then i'll just wait it out.. and use the
<add key="episerver:findcommerce.IgnoreWebExceptionOnInitialization" value="true"/> for the time being
Hi all,
As you may have noticed, the demo cluster is currently experiencing capacity issues. The operations team is aware and will work to remedy this as soon as possible. We are sorry for the inconvenience caused!
Thanks,
Joakim
Hi Vishal, We are currently working on improving the capactity of the Find clusters and trying to limit impacts to availability during this time.
ok you have made it impossible to develop at the moment at least so the impact is not limited.. Would be much appriciated if you could update status.episerver.com for this "improving" feature as well.
Or have a alert on world with these kind of issues.
Hi, Find index is still having issues? Do you know how long this acitivity will take? Hopefully, we can have stable find index soon.
Thanks at least I'm not the only one experiencing issues, 401 unauthorised. When it does work it is extremely slow, makes it hard to get the approval for episerver find use/purchases from management. Hopefully it'll be resolved soon.
Are we able to get an update on this issue? I'm doing a lot of find work in development and it's making it very difficult to progress forward.
They are not working at all now. 401 unauthorised.
I've tried creating new indexes etc still the same.
Hello,
I also just created a new index and receive a 401 error when I try to launch my local development site.
Thank you,
Kevin Larsen
Bump. I'm seeing this still.
I've created two new indexes on my account. Both look like they're created but have a status of NoCreated when viewed through the Find portal. I see 401 when querying.
It's almost like the process that creates them isn't running.
V.Frustrating. An 8 page forum thread of people still experiencing issues......
It might take a while before the index gets created. It might also have been some issue with the cluster at the time, which made it take longer than hoped for. I hope it was created short after the post.
Are there issues with newly created developer indexes? I receive "(401) Unauthorized" errors when indexing and also received nested "IOException[No space left on device]" while indexing last Friday. I have an old index that works just fine on the very same project. I'm confident I have the correct configuration using the correct private url.