FWD » Bugs

ECF's notes on :

The message is based on a Progress error that we emulate in the P2J runtime. It is saying that somewhere in the screen you are trying to bring up, the format string defined for the field (">>>>>>9") is too narrow for the number it is trying to display (120287063). The format string fits up to 7 digits, but the value has 9.

This will require some diagnosis/debugging to determine which field is causing the problem and why the number is wider than the format string. This can simply be the result of "standard" application-domain numbers (like SO, PO, vendor, customer numbers, etc.) getting larger over time, since the original code was not "future-proofed" well to consider larger numbers in many places. Or it may be the result of an unusually large number creeping into the database in some other way (e.g., manually added to the database, added by an external program, added by a user through some screen which has a wider format than 7, etc.).

Since the number in this case is 2 orders of magnitude larger than the format string, I suspect it's not the result of natural growth of the standard numbers. You may want to confirm that the test database you are using hasn't changed since the last time this was working.

The fact that you're seeing it with "V", "I", and especially "R" is probably just because the error already has happened with the first selection of "V" or "I", and the terminal is paused waiting for any key press to display queued error messages from the original problem. You probably should test each option independently from a clean login, to isolate which module actually is triggering the problem.

This is an application-level issue, as far as I can tell from what you've sent. Unfortunately, we are fully consumed and we don't have a lot of time to dig into application issues, other than making sure the custom stuff we've done most recently (like 1677) is working properly. Can you have one of your guys look into this?

As a starting point, I would suggest searching the backing database for a service order number or item number of 120287063, and if you find a record, tracking back to where it might have come from. Another angle would be to look at the programs behind the service order main screen (if "V" is the problematic option) or the inventory main screen (if "I" is the problem), then find all the UI fields with a format string of ">>>>>>9", and see if you can track back to the origin of the 120287063 number using that information.

If it turns out to be a P2J runtime or conversion issue, of course we will fix it.

Constantin: if you can think of any way this might be related to the code merge you just did, please jump in, though it's not obvious to me how it would be.

CA notes:

The problem with not able to display a number is related to excessive hibernate logging (TRACE is enabled, as I recall). As we have P2J data types, the logger tries to do a "toString" to get property values... and toString for i.e. integer values uses the "->,>>>,>>9", which can't cover all values. While the client is waiting for a key press, get a server thread dump, and you will see that some Conversation thread is paused in some hibernate logging code.

John: when we last talked about this, you said that you've fixed it in etc/log4j.properties. My solution was to remove all customer_libs/ (except jasperreports and itext) - I know that this can't be your solution. But, if changing etc/log4j.properties doesn't work, please try my solution, and if the messages disappear, it means that there are log4j settings in some other locations.

Eric,

To solve this with the least amount of code changes in our toString implementations, we can redirect to toStringMessage, if the toString call comes from a known logger API (which can be determined by inspecting the stacktrace and comparing the call stack with known logger APIs). I know this adds some overhead, but to make toStringMessage implementation be the default implementation for toString, I think would mean we will have to replace all toString calls with some toStringP2J implementation in the entire P2J runtime, which I don't know how feasible/easy it is to do.

Thanks,
Constantin

On 12/20/2012 10:53 PM, Eric Faulhaber wrote:

Constantin,

Clearly the default integer.toString() implementation, while appropriate for converted business logic purposes, is getting us into trouble when used for non-business logic purposes (such as logging). We have similar problems with character.toString(), which truncates longer strings to 8 characters. This won't cause error messages like we're seeing below, but it does lose information.

We want the behavior of toStringMessage() in logging and other uses, but of course 3rd party code and the concatenation operator will call toString(). We can't change the toString() implementation of the base data type wrappers without breakage, since converted business logic depends upon the current behavior.

Can you suggest a change we could make in P2J (with as little development impact as possible) to alleviate this issue? This is not a high priority issue at the moment, but I expect we will continue to see this problem crop up at all customers, so I think we will need to address it at some point.

Thanks,
Eric