IsolatedStorageTraceListenerData: The repository is not available

Topics: Logging Application Block, Silverlight Integration Pack
May 22, 2012 at 2:50 PM

Our Silverlight client is logging using the IsolatedStorageTraceListenerData.  However, we routinely see exceptions:

 

======================================
Exception Type: System.InvalidOperationException
Message: The repository is not available. The most likely cause is that the repository file is already being used by another instance.
Data: System.Collections.ListDictionaryInternal
StackTrace Information Details: 
======================================
   at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.IsolatedStorageLogEntryRepository.CheckAvailable()
   at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.IsolatedStorageLogEntryRepository.Add(LogEntry entry)
   at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.IsolatedStorageTraceListener.TraceData(TraceEventCache traceEventCache, String name, TraceEventType eventType, Int32 id, Object data)
   at Microsoft.Practices.EnterpriseLibrary.Logging.LogSource.TraceData(TraceEventType eventType, Int32 id, LogEntry logEntry, TraceListenerFilter traceListenerFilter, TraceEventCache traceEventCache)
   at Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterImpl.ProcessLog(LogEntry log, TraceEventCache traceEventCache)

I suspect the IsolatedStorageTraceListenerData is not thread-safe and this is what happens when one thread attempts to log while another is busy logging.

Can anyone confirm this is the case, or cite another cause?  And, of course, any prescribed solutions?

 

May 23, 2012 at 6:20 AM
Edited May 23, 2012 at 6:24 AM

You could be right.  The actual TraceData call should be thread-safe since a Monitor.Enter is invoked if the TraceListener is not thread-safe (IsThreadSafe).  However, if ApplyChanges() is called at the same time then this could potentially remove the storage reference out from under another Write request which could generate the "repository not available" message.

Can you post a small repro project?

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com 

May 23, 2012 at 11:55 AM

I could try, but I'm not sure where to start.  We have a 2-year development project in beta, with approximately 0.5M LoC in the Silverlight client.  We recently added EntLib 5 Silverlight logging to it, logging to both IsolatedStorageTraceListenerData and RemoteServiceTraceListenerData.  Through the remote listener, we see reports of the isolated listener's occasional failure from our production, beta environment.  However, I've never managed to catch it in the act or even have a clue what portion of the client is leading to this.  So I'm unsure of where to begin and making a repro solution to demonstrate the problem.

May 25, 2012 at 3:05 AM

Threading issues can be difficult to track down.  Can you describe how you are using logging and perhaps post some code snippets?

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com 

Jul 30, 2012 at 8:11 PM

My use of it isn't anything fancy, I don't think.  We have a very rich Silverlight client communicating with our own WCF services.  We've leveraging EntLib 5 logging in the client to isolated storage.  We're also sending errors home through the EntLib ILoggingService/LoggingService.  It seems that occasionally the IsolatedStorageLogEntryRepository is in use from a thread and produces its own error (that then gets sent to the ILoggingService).  I had hoped the repository would be thread-safe on it's own so I wouldn't have to pay special attention to dispatching when logging -- I could do it from the UI thread or a thread pool thread, etc.

Aug 12, 2013 at 10:32 AM
Hi

we are facing now the exact same problem as Trinition explained, did you found any solution for that?
Trinition how did you proceed with that exception?

Regards
Summary for Enterprise Library Distributor Service:
======================================
--> 
Message: 
Timestamp: 7/25/2013 6:29:40 PM
Message: ***********
Category: Logging
Severity: Information
--> TimeStamp: 7/25/2013 6:29:40 PM
--> FullName: Microsoft.Practices.EnterpriseLibrary.Logging.Silverlight, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
--> AppDomainName: Silverlight AppDomain
Exception Information Details:
======================================
Exception Type: System.InvalidOperationException
Message: The repository is not available. The most likely cause is that the repository file is already being used by another instance.
Data: System.Collections.ListDictionaryInternal
StackTrace Information Details: 
======================================
   at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.IsolatedStorageLogEntryRepository.CheckAvailable()
   at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.IsolatedStorageLogEntryRepository.Add(LogEntry entry)
   at Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.IsolatedStorageTraceListener.TraceData(TraceEventCache traceEventCache, String name, TraceEventType eventType, Int32 id, Object data)
   at Microsoft.Practices.EnterpriseLibrary.Logging.LogSource.TraceData(TraceEventType eventType, Int32 id, LogEntry logEntry, TraceListenerFilter traceListenerFilter, TraceEventCache traceEventCache)
   at Microsoft.Practices.EnterpriseLibrary.Logging.LogWriterImpl.ProcessLog(LogEntry log, TraceEventCache traceEventCache)
Aug 19, 2013 at 1:59 PM
Sadly, we never found a solution and have just lived with it. I'm interested in any fresh ideas you may have!
May 13, 2014 at 3:11 PM
randylevy wrote:
Threading issues can be difficult to track down.  Can you describe how you are using logging and perhaps post some code snippets? --Randy LevyEnterprise Library support engineerentlib.support@live.com 
Did anything ever come of this? We're still seeing ~25 of these per day in our production system.
May 16, 2014 at 4:58 AM
Originally, I did some analysis and found a situation that may cause an issue (not sure it is what anyone is seeing, though) but the solution would be to synchronize access. I think without a targeted repro it will be extremely difficult to make progress on tracking down the root cause.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Dec 10, 2014 at 4:05 PM
That's frustrating. We're using this to capture client-side errors for thousands of users, but it means that we'll miss some.