SuperOffice UsageStat service internal server error


Not sure where to report this, so i will try it here, we are noticing a lot of errors in the logs at customers because the SuperOffice usage stat service is down.


"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."

RE: SuperOffice UsageStat service internal server error

I've sent an email to our IT.

Av: Margrethe Romnes 15. apr 2019

RE: SuperOffice UsageStat service internal server error

Hi David,


The service is actually up, I can see calls being made and data coming in (the most recent at 10:58). However, when calling it just with the URL like you have in your post, you are actually asking for the WSDL service documentation - and that is failing. The Superoffice code should never do that, it already knows how to call it. Therefore I am interested in more context around what is happening, as well as pieces of log files that might shed some more light on it.


Av: Marek Vokáč 15. apr 2019

RE: SuperOffice UsageStat service internal server error

Hello Marek,

We saw the following error a lot:

Level: Error
At: 09:06:43

Message: WCF Method Func`2 at failed
Type: System.Exception
at SuperOffice.WcfClientBase`1.Execute[TRetVal](Func`2 method, String url)
at SuperOffice.Contracts.UsageStats.UsageStatClient.TableSize(TableSizeRequest request)
at SuperOffice.CallHome.TableSizeCallHome.CollectAndReport(CollectionLockInfo lockInfo)

Inner Element:
Message: There was no endpoint listening at that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Server stack trace:
at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStream()
at System.ServiceModel.Channels.HttpOutput.Send(TimeSpan timeout)
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.SendRequest(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at SuperOffice.Contracts.UsageStats.IUsageStat.TableSize(TableSizeRequest request)
at SuperOffice.WcfClientBase`1.Execute[TRetVal](Func`2 method, String url)

Environment info:
SingleThreadMode: False
Thread name: SuperOffice.CallHome.TableSizeCallHome
Database type: MSSQL - 13
Database: \\\
SerialNumber: 1500078801
Version: SuperOffice NetServer 8.4 Release (Build: Release84_C-2019.04.09-01)
Version.File: 8.4.7038.013
Version.BuildLabel: Release84_C-2019.04.09-01
ContextIdentifier: Default
MachineName: xxxx
StackTrace: at SuperOffice.Diagnostics.SoLogger.LogError(Exception ex)
at SuperOffice.CallHome.TableSizeCallHome.CollectAndReport(CollectionLockInfo lockInfo)
at SuperOffice.CallHome.PeriodicCallHomeBase.RunCollectionCycle(Object dummy)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart(Object obj)

Last error was around ~9:00 UTC, so it seems it is solved now.

Normally I expect when accessing an .svc that you get the general "This is a Windows© Communication Foundation service. Metadata publishing for this service is currently disabled." message. The internal server error led me to assume that something was wrong on your side.

Av: David Hollegien 15. apr 2019

RE: SuperOffice UsageStat service internal server error

Ok David, thanks for the log. As you say it seems that whatever it was, is solved now. I don't have any fault events in my event logs here, but I may do some more digging in various other places.

In any case, these calls are made by a background thread and should not inconvenience anyone. They are part of the Usage Statistics system, and if they fail they will be retried at some later time.

Curiously enough we do have the metadata generation firmly turned off, but the internal error still happens when you ask for the wsdl by GETing the service url. It has to do with a naming conflict in there, that does not impede normal calls. We have a long-term plan to swap out WCF over time, but since this service is used by on-site installations where I cannot force an upgrade, I will still have to keep the WCF receiver going for some years. Ah well.




Av: Marek Vokáč 16. apr 2019