<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Actually my tests showed that ispn's trace log lines were only written to the AS logs and did not reach capedwarf's handler. So they couldn't have been written to the ispn cache. So I guess our logging is working as it should.<br><br>Sent from my iPad</div><div><br>On 9. apr. 2013, at 20:12, Ales Justin &lt;<a href="mailto:ales.justin@gmail.com">ales.justin@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Yes, afaik, Dan got a ton of trace logs into CD for Ispn.</div><div>But as you can see we explicitly exclude org.infinispan by default.</div><div><br></div><div>I also asked Marko to investigate this.</div><div><br></div><div>-Ales</div><div><br></div><div>On Apr 9, 2013, at 19:25, "James R. Perkins" &lt;<a href="mailto:jperkins@redhat.com">jperkins@redhat.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  
    I don't see anything obvious wrong with the logging deployer. Are
    you seeing log statements from the excluded categories appearing in
    the handlers defined in the WEB-INF/logging.properties file?<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 04/09/2013 12:51 AM, Ales Justin
      wrote:<br>
    </div>
    <blockquote cite="mid:FC607DC0-F6BE-42C4-80BE-C2E2631A8848@gmail.com" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>Hey Dan,</div>
      <div><br>
      </div>
      <div>first, thanks for looking into this!</div>
      <div><br>
        <blockquote type="cite">
          <div dir="ltr">
            <div>I managed to start the app with 3 nodes on my laptop,
              and it inserted a flight in about 26.7 seconds with TRACE
              enabled for org.infinispan. However, when I counted the
              number of cache commands being executed and I got 55000
              (8700 of which went remote), which seems way too much for
              a single insert. (The log file grew by more than 100 MB.)<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Yeah, with trace you get insane number of log lines.</div>
        <div><br>
        </div>
        <div>Although, this seems to show that again our logging doesn't
          really work as expected.</div>
        <div>*&nbsp;<a moz-do-not-send="true" href="https://github.com/capedwarf/capedwarf-jboss-as/blob/master/extension/src/main/java/org/jboss/as/capedwarf/deployment/CapedwarfLoggingParseProcessor.java#L83">https://github.com/capedwarf/capedwarf-jboss-as/blob/master/extension/src/main/java/org/jboss/as/capedwarf/deployment/CapedwarfLoggingParseProcessor.java#L83</a></div>
        <div>As we explicitly exclude logs from the frameworks/libs we
          use internally in CapeDwarf.</div>
        <div><br>
        </div>
        <div>@Luksa: we need to check this, again ... :-)</div>
        <div><br>
        </div>
        <div>@James: do you see any obvious mistakes in our logging
          deployer?</div>
        <br>
        <blockquote type="cite">
          <div dir="ltr">I think there may be a cycle whereas each
            operation on a cache generates a log message, which then
            triggers a change in the Lucene caches, which writes another
            log message, and so on. </div>
        </blockquote>
        <div><br>
        </div>
        <div>That's why we excluded the internal frmwrks/libs in the
          first place.</div>
        <br>
        <blockquote type="cite">
          <div dir="ltr">How does CapeDwarf capture the logs?</div>
        </blockquote>
        <div><br>
        </div>
        <div>See the url above -- we define a new
          handler:&nbsp;org.jboss.capedwarf.shared.log.Logger</div>
        <br>
        <blockquote type="cite">
          <div dir="ltr">I haven't seen any appender in the
            standard-capedwarf.xml configuration. How can I enable TRACE
            logging for org.infinispan without the logs being indexed by
            CapeDwarf?<br>
          </div>
        </blockquote>
        <br>
      </div>
      <div>As I said, it should already work that way -- but
        unfortunately it looks like it doesn't.</div>
      <div><br>
      </div>
      <div>But, hopefully, this should work:</div>
      <div>* you disable org.infinispan explicitly in GAE log file</div>
      <div>--&gt;&nbsp;<a moz-do-not-send="true" href="https://developers.google.com/appengine/docs/java/runtime#Logging">https://developers.google.com/appengine/docs/java/runtime#Logging</a></div>
      <div><br>
      </div>
      <div>Add&nbsp;<strong style="color: rgb(0, 112, 0); font-family: 'Droid
          Sans Mono', monospace; font-size: 13px; line-height: 1.5; "><span class="atv" style="margin: 0px; padding: 0px; border: 0px;
            font-weight: inherit; font-style: inherit; font-family:
            inherit; vertical-align: baseline; color: rgb(0, 136, 0); ">WEB-INF/logging.properties</span></strong>&nbsp;file
        with JUL logging config / properties to helloorm2.war (aka our
        ROOT.war).</div>
      <div><br>
      </div>
      <div>HTH</div>
      <div>Ping me on irc for any other issues.</div>
      <div><br>
      </div>
      <div>-Ales</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
James R. Perkins
JBoss by Red Hat</pre>
  

</div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>infinispan-dev mailing list</span><br><span><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></span></div></blockquote></body></html>