November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
What was the error for the pool to shutdown? I do have site in this combination.
Everything is working fine then suddently (have not found out any clues in why it happens, these two error comes and the application pool dies)
First:
An unhandled exception occurred and the process was terminated.
Application ID: DefaultDomain
Process ID: 12240
Exception: System.Runtime.Serialization.SerializationException
Message: Unable to find assembly 'Lucene.Net, Version=3.0.3.0, Culture=neutral, PublicKeyToken=85089178b9ac3181'.
StackTrace: at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.AppDomain.Deserialize(Byte[] blob)
at System.AppDomain.UnmarshalObject(Byte[] blob)
Then
Application: w3wp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: Lucene.Net.Index.MergePolicy+MergeException
Stack:
at Lucene.Net.Index.ConcurrentMergeScheduler.HandleMergeException(System.Exception)
at Lucene.Net.Index.ConcurrentMergeScheduler+MergeThread.Run()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart()
Stupid question, but do you have Lucene in bin/ folder, all dependencies are satisfied, correct assembly redirects (if any required), pool is able to load a library?
Not a stupid question :-)
The dll is in the bin-catalog and the strange thing is that everything is working and then all of the sudden it crasch.
There are no dependency in the web.config, do you have that in your working version?
I've seen the same error when two sites using different databases are using to the same folder to store the EPiServer Search Index.
The EPiServer Search Index folder can be changed in web.config:
Change Index or even the complete value of the directoryPath attribute to something completely different.
<episerver.search.indexingservice> <namedIndexes defaultIndex="default"> <indexes> <add name="default" directoryPath="[appDataPath]\Index" readonly="false" /> </indexes> </namedIndexes> </episerver.search.indexingservice>
Alf, we store the index in a path that is replicated with dfs, perhaps it has gone wrong so that both servers are trying to index and the dfs are messing up the index-file?
I've not had the opportunity to investigate exactly what's happening, but in our case it seems like that something gets screwed up when EPiServer Search on both sites are trying to work with the same Index file.
It would not surprise me if the actual problem has something to do with more services are trying to work with your file?
Did you work out what was causing the app pool to crash? I've just had the same problem and we are using DFS-R replication (including the index).
For now since we don't need search I'll be disabling it.. but I expect we will need it in the future. I'm assuming I will need to remove the Lucene Index from the DFS-R replication.
We do not know exactly what it was but we think it was that both servers tried to index and that together with dfs did make lucene go nuts.
in a load balanced environment it is importent to set up so only one server is updating the index files and then to replicate them to all servers.
see more in the sdk how to do this, I do not have the links here.
Good luck!
That certainly is what appeared to be occuring. For now I've setup each server with it's own index (not DFS-R shared). It's not an efficient use of resources... but our farms is 10 servers and I don't want to have to keep track as to which is the index server!
Very true Bevan. EPiServer Search is not the best solution when in a big enviroment, it is mutch better to use EPiServer Find as a internal search also, but that will cost extra.
I hope EPiServer will offer a hosted service for the EPiServer Search in the future.
We have upgraded a projekt to Framework 4.5 because we need to use the async await that is only in 4.5 and not in 4.0.
Most things works but we had to disable the EPiServer Search totaly because it crashed the application pool and with that the whole site.
Anyone who have a site with EPiServer 7 and EPiServer Search working with Framework 4.5?