Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Client side loglevel

    Hi,

    We noticed that a lot of log lines (and stack traces) are generated by the ISC_Core, and we expect that this may be the cause for our application feeling sluggish at time. Switching between tabs (within a tab panel) takes up to 10 seconds, while no network activity is initiated at that time. There is however quite a bit of debug logging (hundreds of lines) being generated during that time. So for our production release I'd like to set the loglevel to SEVERE.

    However for some reason I'm not able to find how to change the loglevel for our SmartGWT application. I'd assume I could set this through a property but I'm not able to find how...

    Any tips or pointers would be appreciated!

    Thanks!

    #2
    By editing ISC_Core.js and emptying the log methods I was indeed able to gain a substantial speed improvement. Question is how I can change the loglevel through configuration, as that does not seem obvious through the (minimalized) javascript file itself. Any ideas? Thanks!

    Comment


      #3
      If you are not seeing logs actually appearing in the Developer Console, they have negligible performance impact. So you may have a performance problem for a particular developer who has enabled non-default log settings in his Developer Console, but this would not impact any other users - the log settings are stored in a cookie.

      Setting the default level to SEVERE would do nothing except hide warnings that you need to pay attention to.

      Comment


        #4
        Thanks for your reply.

        Your comment regarding the use of cookies hit the nail on the head. We as developers have used the SmartGWT console in the past, and indeed, have changed the loglevel to DEBUG during development. This caused that, since this is stored in a permanent cookie, that the loglevel was permanently set to DEBUG. And this causes a huge performance hit (even if the browser log console is not opened). Deleting the cookie resulted in the default loglevel to be set to INFO, and the high number of loglines was reduced to a very small amount. And with that, the performance was back to what it should be.

        I do have a suggestion though: Would it be possible to add a feature where it is possible to configure/set the default loglevel for the client application? Secondly, would it be possible to have the cookie, that is set by the debug console when the loglevel is changed, use an empty expiry - meaning it expires when the browser tab is closed. This to prevent the issue we ran into: A DEBUG loglevel configuration lingering around while the user is not aware of that happening.

        Thanks!
        Last edited by Xandrios; 25 May 2018, 02:13.

        Comment


          #5
          You should set the log level back to the default of WARN, otherwise you will have a flood of logs and miss important warnings.

          For the unusual case where you want your end users to have logging enabled, perhaps because you've got a way of automatically capturing and storing it, you can use the underlying SmartClient (therefore JavaScript) API isc.Log.setLogPriority.

          Sorry, but we don't think there's any need to automatically reset log priorities, which would be inconvenient in several use cases. You need to be periodically checking the Developer Console for errors, so it would normally be extremely obvious that you had enabled way too much logging (setting things to DEBUG produces megabytes of output very quickly).

          Comment

          Working...
          X