On Jun 4, 2010, at 4:40 AM, Pascal Robert wrote:
...
- It's a (non public) online store. When people log in, we
create a order in memory and customers add order items to the
order. We don't store anything in the DB until the payment is
made with PayFlow. When we get the response from Pay
...
- It's a (non public) online store. When people log in, we
create a order in memory and customers add order items to the
order. We don't store anything in the DB until the payment is
made with PayFlow. When we get the response from PayFlow, we
store a copy of the order (and the items)
On 2010-06-02, at 11:54 AM, Chuck Hill wrote:
>
> On Jun 2, 2010, at 8:51 AM, Pascal Robert wrote:
>
>>
>> Le 10-06-02 à 11:39, Chuck Hill a écrit :
>>
>>>
>>> On Jun 2, 2010, at 8:16 AM, Pascal Robert wrote:
>>>
Le 10-06-02 à 10:30, Chuck Hill a écrit :
> That makes yo
On 2010-06-02, at 11:51 AM, Pascal Robert wrote:
>
> Le 10-06-02 à 11:39, Chuck Hill a écrit :
>
>>
>> On Jun 2, 2010, at 8:16 AM, Pascal Robert wrote:
>>
>>>
>>> Le 10-06-02 à 10:30, Chuck Hill a écrit :
>>>
That makes your code look guilty then. :-)
>>>
>>> Funny thing is that he n
On Jun 2, 2010, at 8:51 AM, Pascal Robert wrote:
Le 10-06-02 à 11:39, Chuck Hill a écrit :
On Jun 2, 2010, at 8:16 AM, Pascal Robert wrote:
Le 10-06-02 à 10:30, Chuck Hill a écrit :
That makes your code look guilty then. :-)
Funny thing is that he not really my code (eg, I didn't wr
Le 10-06-02 à 11:39, Chuck Hill a écrit :
On Jun 2, 2010, at 8:16 AM, Pascal Robert wrote:
Le 10-06-02 à 10:30, Chuck Hill a écrit :
That makes your code look guilty then. :-)
Funny thing is that he not really my code (eg, I didn't write it)
but this is code dated from WO 5.2. It's j
On Jun 2, 2010, at 8:16 AM, Pascal Robert wrote:
Le 10-06-02 à 10:30, Chuck Hill a écrit :
That makes your code look guilty then. :-)
Funny thing is that he not really my code (eg, I didn't write it)
but this is code dated from WO 5.2. It's just that this app never
had that much traff
FYI, I did a brief test of using WO 5.4.3 on a mature app a week or two ago,
and running a barrage of Selenium tests (where each test generally created a
new Session with a specific user on a specific page with a master EO) would
deadlock some of the Sessions' defaultERXEC's every time. Switchin
Le 10-06-02 à 10:30, Chuck Hill a écrit :
That makes your code look guilty then. :-)
Funny thing is that he not really my code (eg, I didn't write it) but
this is code dated from WO 5.2. It's just that this app never had that
much traffic.
And I did try stress loading this app with JMe
Le 10-06-02 à 10:35, Mike Schrag a écrit :
doesn't addCooperatingObjectStore have a race condition in <=5.4? i
don't recall if wonder fixed that or not ...
I guess we could try with WO 5.4.3, but about Wonder, the app is
extending from ERXApplication/ERXSession. Wonder download from two
doesn't addCooperatingObjectStore have a race condition in <=5.4? i don't
recall if wonder fixed that or not ...
On Jun 2, 2010, at 8:19 AM, Pascal Robert wrote:
> ... And going back to the physical server didn't solve anything, I got the
> same deadlock this morning.
>
>> Ok, so I will move b
That makes your code look guilty then. :-) Check your long response
page implementation again. Are there any exceptions in the log that
might be related?
I'd also reduce the Maximum Adaptor threads (JavaMonitor ->
Application configuration -> Application settings). 6 or 8 is
probably
... And going back to the physical server didn't solve anything, I got
the same deadlock this morning.
Ok, so I will move back the DB to the physical server to see if the
problem goes away.
On Jun 1, 2010, at 6:34 AM, Pascal Robert wrote:
Hum... And after I started using ERXWOLongRespons
Ok, so I will move back the DB to the physical server to see if the
problem goes away.
On Jun 1, 2010, at 6:34 AM, Pascal Robert wrote:
Hum... And after I started using ERXWOLongResponsePage, I still got
a deadlock, but this time, it says that it's a EODatabaseContext
lock :
Thread t..
On Jun 1, 2010, at 6:34 AM, Pascal Robert wrote:
Hum... And after I started using ERXWOLongResponsePage, I still got
a deadlock, but this time, it says that it's a EODatabaseContext
lock :
Thread t...@92163: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Interpreted frame)
- java.
We have a component, OSLongResponseComponent, that was extending from
WOLongResponsePage, and now it's extending from ERXWOLongResponsePage.
The only thing we are overriding is valueForKeyPath and
appendToResponse, run() is not overriden.
Um. Just how did you switch to ERXWOLongResponsePage
Um. Just how did you switch to ERXWOLongResponsePage? If you overrode run()
than nothing's gonna happen.
Cheers, Anjo
Am 01.06.2010 um 15:34 schrieb Pascal Robert:
> ERXWOLongResponsePage
___
Do not post admin requests to the list. They will be igno
Hum... And after I started using ERXWOLongResponsePage, I still got a
deadlock, but this time, it says that it's a EODatabaseContext lock :
Thread t...@92163: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, line=474 (Interpreted fra
Another thing to note if this is a long request to a database housed in an ESX
vm. We had similar problems with long requests timing out between two systems,
with one hosted by esx 4.x. Such long requests were caught by some low level
interface muxing issue and my whole EOF stack was frozen when
Ok, will try with ERXWOLongResponsePage since it look like it's
locking and unlocking all ECs in the thread.
There's a bunch of stuff wrong here. First, the only actually locked
thread is:
-
com
.webobjects
.eocontrol
.EOObjectStoreCoordinator
.addCooperatingObjectStore
(com.webobjec
There's a bunch of stuff wrong here. First, the only actually locked thread is:
-
com.webobjects.eocontrol.EOObjectStoreCoordinator.addCooperatingObjectStore(com.webobjects.eocontrol.EOCooperatingObjectStore)
@bci=5, line=130 (Interpreted frame)
-
com.webobjects.eoaccess.EODatabaseChannel.set
21 matches
Mail list logo
