Antonio Gallardo <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter dijo: > > I'm not sure I even see a reason for logging it at INFO? If you've > > got an error that occurs because the client closed the > socket you're > > either going to know this, or if you turn up logging to the > INFO level > > to try and find this out you're going to need some way to reproduce > > the error that doesn't swamp the log and hope that you the > same set of > > circumstances once more. IOW, how would the information ever be > > useful? > > Hi Peter: > > This thread is really interesting to me. I thought about this > issue before, because in fact this is not a Cocoon error. > This is just an event that can be logged. The exception is > thrown because the user side closed the connection (maybe the > user closed the browser or a blue screen of death on the > client stoped the connection or all the posible causes.). I > think we can agree in this point. > > Then the second question is at what level we will log this > event? I suggested at INFO level because if we log this as an > erro, then some user can be alarmed without cause and will > try to solve it wasting just time because they cannot do > nothing on Cocoon side. This is why to me this is not an > error on the cocoon side and I suggested INFO or maybe > WARNING for log the event. > > On the other side, if someone needs to check how often it > happen and why then maybe he needs to set to INFO or WARN this event. > > WDYT?
Got me.... I can't really see how the information would ever help? If the user keeps closing the session the error doesn't tell you why, just that it happened. If it's an error on the client side and I personally can't see that I care about it on the server (Cocoon) side. If the user has a real support issue they need to get a support person to work with them on what is happening on the client side? The exception (no pun intended) to this might be if somehow it's the Cocoon data stream that is causing the close. I guess in theory you might be able to use INFO level logging to figure this out, but like I said, it's going to be a lot of data, I suspect you'll end up swamped with data. It would likely be easier to debug from the client side in this case also?
