Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2.11
    • Fix Version/s: 1.2.12
    • Component/s: Appenders, Core
    • Labels:
    • Environment:
      Any

      Description

      I have a solution with a console application (.Net 4 and log4net v1.2.11) which implement the Remoting sink - server side. And a WPF or WindowsForms application - client side. The framework version on the client side doesn't matter. But the log4net version is different. On v1.2.10 anything is ok. When I reference the client with v1.2.11 throw this error:

      log4net:ERROR [RemotingAppender] ErrorCode: GenericFailure. Failed in SendBufferCallback
      System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'WpfTestApplication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
      at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
      at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
      at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)
      at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
      at System.Reflection.Assembly.Load(String assemblyString)
      at System.Runtime.Serialization.FormatterServices.LoadAssemblyFromString(String assemblyName)
      at System.Reflection.MemberInfoSerializationHolder..ctor(SerializationInfo info, StreamingContext context)
      — End of inner exception stack trace —

      Server stack trace:
      at System.RuntimeMethodHandle._SerializationInvoke(IRuntimeMethodInfo method, Object target, SignatureStruct& declaringTypeSig, SerializationInfo info, StreamingContext context)
      at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(Object obj, SerializationInfo info, StreamingContext context)
      at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder)
      at System.Runtime.Serialization.ObjectManager.DoFixups()
      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.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
      at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

      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 log4net.Appender.RemotingAppender.IRemoteLoggingSink.LogEvents(LoggingEvent[] events)
      at log4net.Appender.RemotingAppender.SendBufferCallback(Object state)

      1. LOG4NET-341.patch
        18 kB
        Dominik Psenner

        Activity

        Hide
        Dominik Psenner added a comment -

        Would you please append a stacktrace?

        Show
        Dominik Psenner added a comment - Would you please append a stacktrace?
        Hide
        Dominik Psenner added a comment -

        Did You build the client against log4net 1.2.10 and the server against 1.2.11 (or vice-versa)?

        Show
        Dominik Psenner added a comment - Did You build the client against log4net 1.2.10 and the server against 1.2.11 (or vice-versa)?
        Hide
        Dominik Psenner added a comment - - edited

        I would assume that this problem arises when the log4net versions of client/server do not match but that isn't the case if I interpret your last comment correctly. Unfortunately I cannot triage the problem like this. Would you please share with us a small sample solution that reproduces the problem? That solution can be an archive of your choice (preferably .tar.gz) containing the sources and a small step-by-step howto to reproduce the situation (i.e. something like start server, wait 3min, start client, click button X on client).

        Show
        Dominik Psenner added a comment - - edited I would assume that this problem arises when the log4net versions of client/server do not match but that isn't the case if I interpret your last comment correctly. Unfortunately I cannot triage the problem like this. Would you please share with us a small sample solution that reproduces the problem? That solution can be an archive of your choice (preferably .tar.gz) containing the sources and a small step-by-step howto to reproduce the situation (i.e. something like start server, wait 3min, start client, click button X on client).
        Hide
        Dominik Psenner added a comment - - edited

        I just tried your first version of the logging.zip and it worked for me with both applications running and clicking like a weirdo. Please see the attached screenshot.

        Show
        Dominik Psenner added a comment - - edited I just tried your first version of the logging.zip and it worked for me with both applications running and clicking like a weirdo. Please see the attached screenshot.
        Hide
        Dominik Psenner added a comment - - edited

        There's something fishy going on with how log4net 1.2.11 serializes log events to be sent to the server on client side. It most probably includes some information that the server can deserialize only if the calling assemblies of the 1.2.11 client are available to him. I'll have to bisect the revision since when it is broken and this could take some time. Please be patient. Until then it should work if you have the client assemblies available on server side (a simple copy paste is enough).

        Show
        Dominik Psenner added a comment - - edited There's something fishy going on with how log4net 1.2.11 serializes log events to be sent to the server on client side. It most probably includes some information that the server can deserialize only if the calling assemblies of the 1.2.11 client are available to him. I'll have to bisect the revision since when it is broken and this could take some time. Please be patient. Until then it should work if you have the client assemblies available on server side (a simple copy paste is enough).
        Hide
        Dominik Psenner added a comment -

        I bisected it to revision 778073 and revision 778271. The commit log says:

        Fix for LOG4NET-154. Added StackTracePatternConverter that outputs the methods called before the log message.

        http://svn.apache.org/viewvc?view=revision&revision=778271

        My guess that since then a logevent holds a reference to the client assembly was probably right. The reference comes from the stacktrace (location) information.

        Good is that we now know what goes wrong, but I don't know a way to fix it without breaking the StackTracePatternConverter functionality. The problem is that the server cannot half deserialize a logging event by ignoring the stacktrace information. And on the other hand the client must send that information along with the log event to the server since the client does not know if the server wants to access that information.

        So there are 2 options now:

        1-FIX] Rewrite the StackTracePatternConverter so that it clones the stacktrace information into a meta structure that does not hold a reference to the calling assembly. This will take time and I can't give you any estimates.

        2-HOTFIX] Make the client assembly accessible at server side. The best option here is to add a dependency on the client project so that visual studio builds the client stuff into the server.

        Show
        Dominik Psenner added a comment - I bisected it to revision 778073 and revision 778271. The commit log says: Fix for LOG4NET-154 . Added StackTracePatternConverter that outputs the methods called before the log message. http://svn.apache.org/viewvc?view=revision&revision=778271 My guess that since then a logevent holds a reference to the client assembly was probably right. The reference comes from the stacktrace (location) information. Good is that we now know what goes wrong, but I don't know a way to fix it without breaking the StackTracePatternConverter functionality. The problem is that the server cannot half deserialize a logging event by ignoring the stacktrace information. And on the other hand the client must send that information along with the log event to the server since the client does not know if the server wants to access that information. So there are 2 options now: 1-FIX] Rewrite the StackTracePatternConverter so that it clones the stacktrace information into a meta structure that does not hold a reference to the calling assembly. This will take time and I can't give you any estimates. 2-HOTFIX] Make the client assembly accessible at server side. The best option here is to add a dependency on the client project so that visual studio builds the client stuff into the server.
        Hide
        Dominik Psenner added a comment -

        Patch that should resolve this problem and now open to discussion.

        Show
        Dominik Psenner added a comment - Patch that should resolve this problem and now open to discussion.
        Hide
        Dominik Psenner added a comment -

        Please note that this patch breaks backwards compatibility to ALL prior versions of log4net. If the server is built with another version of log4net than the client the server will now always crash in favor of not needing a reference to the calling assembly on server side anymore. However I'm not a great fan of this - comments and ideas are welcome!

        Show
        Dominik Psenner added a comment - Please note that this patch breaks backwards compatibility to ALL prior versions of log4net. If the server is built with another version of log4net than the client the server will now always crash in favor of not needing a reference to the calling assembly on server side anymore. However I'm not a great fan of this - comments and ideas are welcome!
        Hide
        Stefan Bodewig added a comment -

        I think this kind of backwards incompatibility is acceptable - although I'd prefer to talk about that on the dev list rather than hidden inside of the comments of a JIRA ticket 8-)

        @Dominik, have you forgotten to check the "grant license to the ASF" checkbox or do you really mean to not contribute the patch?

        @Sandra, the code hasn' t been added to the source code repository ans much less to any release. For the fix to have any impact for you you'd have to use the next version of log4net - whenever that may become available - on both sides, client and server.

        Show
        Stefan Bodewig added a comment - I think this kind of backwards incompatibility is acceptable - although I'd prefer to talk about that on the dev list rather than hidden inside of the comments of a JIRA ticket 8-) @Dominik, have you forgotten to check the "grant license to the ASF" checkbox or do you really mean to not contribute the patch? @Sandra, the code hasn' t been added to the source code repository ans much less to any release. For the fix to have any impact for you you'd have to use the next version of log4net - whenever that may become available - on both sides, client and server.
        Hide
        Dominik Psenner added a comment -

        Commited patch as of revision: 1486883

        Please note that the patch introduces a backwards incompatibility and cannot interoperate with older versions of log4net.

        Show
        Dominik Psenner added a comment - Commited patch as of revision: 1486883 Please note that the patch introduces a backwards incompatibility and cannot interoperate with older versions of log4net.

          People

          • Assignee:
            Dominik Psenner
            Reporter:
            Sandra Neumann
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development