+1, sounds like a good backport for 1.3 :)
On 6/21/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i would like to make button.onsubmit() abstract in 2.0 branch because it
doesnt make much sense not to override and being abstract it will guide
users better.
anyone against?
-igor
We are observing a large number of open files (Jars, such as
wicket-extensions, wicket) when running in development mode. It seems to be
related to the scanning of Jars.
After a day or two, we run out of file handles.
Anyone else seen this??
Switching to Deployment, and we don't see any open
Preregistration of package resources is not nesesarry anymore, so that
should save a few. For the rest, it's the reloading mechanism we have
in place for development. Unfortunately, it's a JDK bug as far as I
know, so besides advising to not turn on template/ properties file
reloading, I'm afraid
This is a known issue. It is actually a bug in Java (I think it is in
the top 25 of bugs nowadays). You can find the discussions on the list
with respect to the bug.
Sad thing: it won't be fixed in mustang.
The only solution is to deploy your applications in 'deployment' mode,
or set the
Bugs item #1509831, was opened at 2006-06-21 11:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=684975aid=1509831group_id=119783
Please note that this message will contain a full copy of
Sorry, I meant getNestedModel of course (as there's no such thing as
getWrappedModel).
Matej Knopp wrote:
Hi,
I'm going through the big model change in 2.0 and I noticed that now we
have IWrapModel, but IModel still contains getWrappedModel().
Wouldn't it be cleaner if the
I'm looking bit deeper and it seems that the semantics of IWrapModel is
slightly different than I though, so just silently ignore the question :)
Matej Knopp wrote:
Sorry, I meant getNestedModel of course (as there's no such thing as
getWrappedModel).
Matej Knopp wrote:
Hi,
I'm going
Hi,
we have a problem with session locking. Sometimes, the underlying
database just hangs and the response is not processed properly. The
problem is that HttpSession remains locked.
Wouldn't it be possible to replace the current locking mechanism
( synchronized(lock) { doEverything() } )
not unless all page targets return the same mutex instance :)the point is that only a single page is processed at a time because of pagemap, etc. although i dont really know if the pagemap is affected all that much in
2.0.but even then, lets say i double click a link really fast, i get two
It seems to me that this synchronization also
affects other requests (not only Page). We have a page with images taken from
database. The images appear one by one instead of "simultaneous"...
Jan
"Igor Vaynberg" [EMAIL PROTECTED]
wrote in message news:[EMAIL PROTECTED]...not
unless
in 1.2 we refactored things so that resources do not necessarily sync on session. if you are using the Image component - then i think yes it will sync on session because Image component is part of the page...johan would know best since he did most of the refactoring
-IgorOn 6/21/06, jan_bar [EMAIL
Igor Vaynberg wrote:
not unless all page targets return the same mutex instance :)
The mutex would be stored in session of course :)
the point is that only a single page is processed at a time because of
pagemap, etc. although i dont really know if the pagemap is affected all
that much in
or expand the war into a directory structure
Juergen
On 6/21/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
This is a known issue. It is actually a bug in Java (I think it is in
the top 25 of bugs nowadays). You can find the discussions on the list
with respect to the bug.
Sad thing: it
but you wouldnt want to unlock the mutex, thats kinda the whole point! what if both pages access session object? or application object? now you have to start worrying about concurrency on those. the advantage of letting only one page request through at a time is that users dont have to think about
Well, it would be your responsibility not to touch application or
session if the mutex is unlocked. This is not something an average joe
would do in every link handler. You would do that only right before a
long db operation and lock it right after it.
I'm not looking for perfect solution. I'm
in that case we sort of already have a mechanism for that, request target has a getlock() which you can override and return something other then session, just need a way to encode a url so it is resolved to your own target
-IgorOn 6/21/06, Matej Knopp [EMAIL PROTECTED] wrote:
Well, it would be
Sorry, i'm lost. How is overriding getlock() supposed to help me? I need
to lock the session, but not for the whole request. Just for a part
before the db call and the part after.
-Matej
Igor Vaynberg wrote:
in that case we sort of already have a mechanism for that, request
target has a
If there was something like
RequestCycle.lockSession()
RequestCycle.unlockSession()
where in my onClock handler I could call
RequestCycle.get().unlockSession()
--do-my-stuff-and-don't-touch-the-session!
RequestCycle.get().lockSession()
I know this adds responsibility to the developer, but this
the page targets are too flexible to support something like this because they do not lock on session specifically - the implementation just happens to do that now. and this would also require us to completely change how we do locking/refactor requesttargets possibly, etc.
we should run this past
I'm also curious what other devs would say. New thread could solve this
but it's not the solution i'm looking for.
I think the locking should be more flexible then just
synchronized(myBFLock) {
processTheWholeRequest();
}
even if it needs additional refactor.
(Maybe RequestTarget#lock
If we can can rid of it, all the better. I don't think the semantics
are great, and they are covered through other means now. If we remove
getNestedModel, we should also remove
wicket.Component#sameRootModel(wicket.Component) and
wicket.Component#sameRootModel(IModel) and update the documentation.
I think providing unlocking functionality is not the way to go. You
basically just provide a hack opportunity if you do that, and that's
not what a framework should do. I'm not really getting the problem at
this point, but if we have a possible deadlock in our request
handling, that's obviously a
I don't know if it can be considered a deadlock, but basicaly, if (for
any reason) a request doesn't complete (db problem, etc), no further
requests from the same session can be processed.
Now maybe if you have perfect business objects that's not an issue, but
in our current project we depend
We could consider building in a time out for the lock itself. That
timeout should be configurable. I agree that being able to hang up the
session is definitively not what we should want.
Eelco
On 6/21/06, Matej Knopp [EMAIL PROTECTED] wrote:
I don't know if it can be considered a deadlock, but
Patches item #1510238, was opened at 2006-06-21 21:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=684977aid=1510238group_id=119783
Please note that this message will contain a full copy
I agree with Eelco. We had a lot of problems in our project with pages
getting expired due to too lax locking. I'm not running to open up
that can of worms again by relaxing the session locks.
On the other hand, we have experienced hanging sessions as well. I
haven't looked into it, as it doesn't
I'm I the only one with this issue?
Hi,
I see your points. In my opinion, *any* database query (but not only
database) can be long operation. At that time your code is sitting in idle
loop waiting for database (located on another PC). In that time the CPU can
do other useful job for the same
well, in order to not let the internal state be corrupted requests have to be processed in sequence they originated from the user. a good and easy way to do this is to lock on session making sure that requests from that user are basically serialized. we really havent found a better way to do this.
28 matches
Mail list logo
