Truncated exception message

[Guest]

Hello We have noticed that the exception message is truncated to around 1000 characters. We need to include more characters. How can we increase this number in our Java client? Best regards, Mads Tandrup APC by Scheider Electric

[Guest]

Hi Mads and sorry for the delayed response You are absolutely right that we have capped the size of the exception message at 1000 characters. This is done to ensure a relatively well defined size of the potential payload and to allow us to tune the overall system performance. While we do have some ways of allowing the monitor to report more than 1000 characters, our server side code is the piece of the puzzle that is less flexible for such changes and we have traditionally not been too keen on allowing "unlimited" amounts of data internally in our payloads. Due to these issues I'm sorry to say that there are no immediate solutions to your question. I'll raise the issue internally though to perhaps see how a workaround could be resolved. Just out of curiosity, what exception messages are growing so large that they do not fit within 1000 characters? I'm wondering if it is a common scenarios that we perhaps need to support better? Hope this answered your question, although it was not an immediate solution. We'd love to hear more details from you on this. Best regards Soren EQATEC Team

[Guest]

Hi S?ren We have some special exceptions concerned communication errors with our server, were the message contains a large amount of useful debug information. If an error occurs when we are communicating with our server, we almost always get more or less the same exception and stack trace. We have there changed our code to throw more specialized exceptions. Some of these special exception include some big messages with debug information. Can we for these special exceptions somehow replace the stack trace with this debug information? Since it would be more useful than a stack trace that only says that an error occurred while communicating with the server. Best regards, Mads

[Guest]

Hi Mads We have no hooks for replacing internal content such as the stacktrace so that is not really the way to go. Here is what I am thinking: If you are already throwing specialized exception perhaps you could look into identifying the ones with large amounts of data and instead of tracking the exceptions you could use our sendLog to send the full debug message. There is an overload to the sendLog that accepts binary data and a mime-type so you could send your textual debug message to our servers. Since it is specialized exception messages you create and catch again, you could (somewhat) easily determine which exception types should be tracked as exceptions and which should track their exception message as a sendLog. Hope my explanation makes sense, otherwise I'll be happy to elaborate. Best regards Soren EQATEC Team