cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Baldwin <jfbald...@earthlink.net>
Subject Re: Odd error
Date Wed, 08 Feb 2012 17:30:18 GMT
I will look into P6Spy, and post the results.

Thanks
Joe



On Feb 8, 2012, at 11:58 AM, Mike Kienenberger wrote:

> I was just trying to restate what other people said.   I don't have
> anything original to add, unfortunately.
> 
> One thing you can do is to insert the P6Spy database driver into your
> app -- this jdbc driver wrapper will provide logging at the jdbc
> level, which would let you see what's going on without having to
> enable java logging.
> 
> Mysql might also have the ability to log but I'm not really familiar with it.
> 
> On Wed, Feb 8, 2012 at 11:51 AM, Joe Baldwin <jfbaldwin@earthlink.net> wrote:
>>> And your next step is to determine how the sort orderings are different (by looking
at the log results), determine why a certain sort causes a problem,
>> 
>> OK, but I have absolutely no idea what you are talking about. :)  More importantly,
I am not sure if I have described the test results well enough. Let me try again:
>> 
>> Succinct Problem Symptoms (to date)
>> 1. The FK error is generated 100% of the time (not intermittently) when I tried to
add a Product entity.  In addition, simply logging into to my app (accessing the admin table),
trigger the FK error for the Product - which was totally illogical since logging into admin
does not INSERT a Product entity.
>> 2. I restarted tomcat and did a recursive "touch" on the JSP dir each time I performed
the test to presumably clear out the memory and cache.
>> 3. The ONLY condition that results in a successful test is to use my development
tomcat (on my OSX laptop), or set Cayenne logging to DEBUG on the production machine.
>> 
>> Confusion:
>> 1. I do not know how these symptoms  might point to a "sort ordering" issue based
on the available test results.
>> 2. If the problem *NEVER* occurs while logging is set to DEBUG, then how would I
check the logs as you suggest?
>> 
>> This is why I have suggested that this problem is "insane"; This is sort of like
a perverted Heisenberg Uncertainty Principle. :)
>> 
>> Question (Based on the "DEBUG Uncertainty Principle"):
>> 1. If the FK problem ONLY occurs with DEBUG set to FALSE then I have limited visibility
into the problem.
>> 2. If I set DEBUG to TRUE all the time, then I am concerned I am simply hiding a
bug.
>> 3. Of course, if I set DEBUG to TRUE, then it is "Miller Time" :)
>> 
>> I have the feeling like some configuration file parameter might be corrupted.  If
nobody has any other ideas (give the visibility constraints), then I guess I will try to rebuild
the project cayenne config files from scratch and hack it into submission. :)  (Not looking
forward to this option.)
>> 
>> Thanks
>> Joe
>> 
>> 
>> 
>> On Feb 8, 2012, at 11:18 AM, Mike Kienenberger wrote:
>> 
>>> Oops.  Didn't finish.
>>> 
>>> And your next step is to determine how the sort orderings are
>>> different (by looking at the log results), determine why a certain
>>> sort causes a problem, and then subclass the sorter to insure it sorts
>>> in a consistently-valid manner each time.
>>> 
>>> On Wed, Feb 8, 2012 at 11:15 AM, Mike Kienenberger <mkienenb@gmail.com>
wrote:
>>>> I think what Michael is saying is that the ashwood sorter isn't
>>>> guaranteed to return the same results for the same commit operation on
>>>> the next run after the application is restarted.   So setting the
>>>> logging wasn't what caused the change -- it was restarting the app.
>>>> 
>>>> On Wed, Feb 8, 2012 at 11:02 AM, Joe Baldwin <jfbaldwin@earthlink.net>
wrote:
>>>>> Well, if it is not "insane", then what should I do?  I mean if the app
only works correctly when logging is set to DEBUG then I would think that indicates a problems.
 I could run the app with DEBUG on all the time, but that would just be covering up what I
would assume is a serious problem.  What should I do next to debug this problem?
>>>>> 
>>>>> More info:
>>>>> Each time I update my project jar file, I do a recursive "touch" (which
I have found forces tomcat to recompile all the jsp's and recognize the new jar file).  After
this, I restart tomcat.  There was a problem with the webhost's configuration of tomcat caching
static variables from the previous jar file into jsp static non-variables.   I would *presume*
this would clear out everything, but maybe not.
>>>>> 
>>>>> On Feb 8, 2012, at 9:14 AM, Michael Gentry wrote:
>>>>> 
>>>>>> On Tue, Feb 7, 2012 at 6:03 PM, Joe Baldwin <jfbaldwin@earthlink.net>
wrote:
>>>>>>> 2. So I found their log4j.properties file and inserted "log4j.logger.org.apache.cayenne.access.QueryLogger=DEBUG"
 (I hope this is what you were thinking of)
>>>>>> 
>>>>>> I actually think you want INFO instead of DEBUG.
>>>>>> 
>>>>>> 
>>>>>>> 4. Rod Serling moment: when I tried to add the Product entity
- for the first time it did not fail
>>>>>>>        - detail: it added the Product, there was no Exception
>>>>>>>        - I verified the Product by listing all of my products
>>>>>>> 
>>>>>>> So, is this 1. Insane, or 2. totally Insane?
>>>>>> 
>>>>>> I've seen AshwoodEntitySorter produce different insert orderings
>>>>>> before from different starts.  Since you shutdown the application,
AES
>>>>>> would have to produce a new dependency graph on startup.  I'm not
>>>>>> saying this is responsible, but it is a possibility.  So: 0. Maybe
not
>>>>>> insane.  :-)
>>>>>> 
>>>>>> mrg
>>>>> 
>> 


Mime
View raw message