I've added a brief entry in the FAQ page on the wiki
(http://cwiki.apache.org/confluence/display/WICKET/FAQs)
Loren
Eelco Hillenius wrote:
This would make a fine entry for a FAQ (which we don't have yet?) on
the WIKI. Any volunteers?
Eelco
--
View this message in context:
PROTECTED]] *On Behalf Of
*Nino Wael
*Sent:* 27. november 2006 14:58
*To:* wicket-user@lists.sourceforge.net
mailto:wicket-user@lists.sourceforge.net
*Subject:* Re: [Wicket-user] Too many open files
Yeah, its in DEPLOYMENT mode… NO it wasn't L We changed
On 11/27/06, James Carnegie [EMAIL PROTECTED] wrote:
Hi all,
This problem has cropped up a couple of times on this list.
Do you think we should add it to the Gotchas section of the wiki?
just my 2 cents. :)
/j.
We should.
Eelco
* James Carnegie:
This problem has cropped up a couple of times on this list.
Do you think we should add it to the Gotchas section of the
wiki?
This issue is a real show stopper. Several users have reported to
me with painful setting into production of Wicket apps.
IMO we should
IMO we should disable the shaky code that reloads templates from
JARs (shaky not because of Wicket, but because of the JVM), and
provide a setting to *optionally* re-activate it for the few users
that really need this.
I'm also in favor of turning this off by default, but in a slightly
On 11/27/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
provide a setting to *optionally* re-activate it for the few users
that really need this.
All users really need this when developing. We already have two modes
for operation: development and deployment. It is not that hard to
comprehend
On 11/27/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 11/27/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
provide a setting to *optionally* re-activate it for the few users
that really need this.
All users really need this when developing. We already have two modes
for operation:
On 11/27/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
We could add to the quickstart project's pom a filter that alters the
mode from development to deployment when a war is built.
But why not make deployment the default. Really, that makes so much
more sense to me.
Because then you have to
On 11/27/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 11/27/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
We could add to the quickstart project's pom a filter that alters the
mode from development to deployment when a war is built.
But why not make deployment the default. Really, that
I like this idea too.
Perhaps Wicket should also output in the logs something like.. developement
mode active, remember to switch to production mode when going live...
That way I think you guys have covered every chance to help users of wicket.
/Flemming
On 11/27/06, Eelco Hillenius [EMAIL
@lists.sourceforge.net
mailto:wicket-user@lists.sourceforge.net
*Subject:* Re: [Wicket-user] Too many open files
Yeah, its in DEPLOYMENT mode… NO it wasn't L We changed it on the
way because, our NICE error pages aren't shown in DEPLOYMENT mode.
THANKS, this fixes our trouble
Perhaps Wicket should also output in the logs something like.. developement
mode active, remember to switch to production mode when going live...
We actually already do that. Maybe we could do it more obviously,
though otoh you don't want Wicket to output too much either.
Eelco
Yes, but not the small addition (which might have helped others)
Remember to switch to production mode (web.xml)
or another way to signal that development mode is not good for production
:-)
/Flemming
On 11/27/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Perhaps Wicket should also output
On 11/27/06, Flemming Boller [EMAIL PROTECTED] wrote:
Yes, but not the small addition (which might have helped others)
Remember to switch to production mode (web.xml)
or another way to signal that development mode is not good for production
:-)
Fair enough. Anyone in the game for opening up
ha!
why is everybody so pro deployment mode as default?
When i was busy doing the changes in that area (adding the system property
and so on)
i asked and wanted to have deployment as default but back then i was
vetoed..
another thing. We need to check in jar files!! Please remember the osgi
I see you use tomcat so what you could try is antiResourceLocking and antiJarLocking of a tomcat context:http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Standard%20Implementation
johanOn 11/13/06, Nili Adoram [EMAIL PROTECTED] wrote:
Hi all,When running our Wicket based web application
This would make a fine entry for a FAQ (which we don't have yet?) on
the WIKI. Any volunteers?
Eelco
On 11/13/06, Johan Compagner [EMAIL PROTECTED] wrote:
I see you use tomcat so what you could try is antiResourceLocking and
antiJarLocking of a tomcat context:
And i don't think we know it directly where the jars come fromis ofcourseAnd i don't think we know it directly where the resources come from (jars or dirs or zips, inside a war..)
On 11/13/06, Johan Compagner [EMAIL PROTECTED] wrote:
drop in a new jar when using it with for example OSGI.And i
drop in a new jar when using it with for example OSGI.And i don't think we know it directly where the jars come fromWe just get an URL from the app server. In that url you can have a jarurlconnection yesBut that is completely depended on the implementation of the app server.
On 11/13/06, Nili
This solves the problem of course.
However, why does the ModificationWatcher look for modified resources
within wicket jars?
If component A extends component B, the MarkupCache should indeed verify
watch B as well unless it is a wicket component.
Why would anyone replace markup inside a wicket
Have you tried upgrading to 1.2.3? There are some fixes for something like that in it AFAIK.FrankOn 11/13/06, Nili Adoram
[EMAIL PROTECTED] wrote:Hi all,When running our Wicket based web application as well Nagios on the same machine
we come across Too many open files problem.We are using soft
You probably run in development mode? Set it to development and your
problems should be gone.
context-param
param-nameconfiguration/param-name
param-valuedeployment/param-value
/context-param
Upgrading shouldn't solve any particular problems here I think,
Hmm this discussion has not ended in a good way.
The problem isn't the way we configure things. Eelco asked whether or
not we could check and drill down what is causing this.
At topicus we run into this problem as well (and for the well
informed: KJB also voted on the sun bug :)
Martijn
On
Eek, XML files! ;)
That aside, I assume this means there is a bug in resource polling? ...
or is it normal for it to open all these files and never close them?
Gili
Igor Vaynberg wrote:
seems there is a problem with how application.configure() works.
if you call
No this is already discussed long time ago on this mailing list.It is a bug of sun. We can't do ONE thing about it.. It really sucks i know but its out of our hands.Here is the bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4950148Please vote for it, because we as wicket really have
+1 calling configure youre self doesn't make anysense.This is one thing that just have to be configured somewhere else (web.xml or system property)johanOn 2/19/06,
Igor Vaynberg [EMAIL PROTECTED] wrote:
seems there is a problem with how application.configure() works.if you call
I'm somewhat confused by now this relates. Why would this result in thousands of extra open files? Wouldn't it just be one open file per URLClassLoader?On 2/19/06,
Johan Compagner [EMAIL PROTECTED] wrote:
No this is already discussed long time ago on this mailing list.It is a bug of sun. We can't
don't know how it reports that,But it seems to report a connection to that jar file that is made for every entry in the jar file.johanOn 2/19/06,
Jesse Sightler [EMAIL PROTECTED] wrote:
I'm somewhat confused by now this relates. Why would this result in thousands of extra open files? Wouldn't it
Is there a way to pool JarFile instances so we reuse the same one every
second instead of creating a new one? Also, maybe we can create our own
UrlClassLoader (copy Sun's and add a closing mechanism which Wicket
would use)?
Gili
Johan Compagner wrote:
No this is already discussed long
I'm -1 on this.
Gili
Johan Compagner wrote:
+1 calling configure youre self doesn't make anysense.
This is one thing that just have to be configured somewhere else
(web.xml or system property)
johan
On 2/19/06, * Igor Vaynberg* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
i think we can detect if its a jar or not, dont jar urls have a ! in them after jar name?-IgorOn 2/19/06, Johan Compagner
[EMAIL PROTECTED] wrote:don't know how it reports that,But it seems to report a connection to that jar file that is made for every entry in the jar file.
johanOn 2/19/06,
That seems EXTREMELY unlikely. If this were the case, I would think a lot of apps would have fairly major and constant problems with open file limits. Why would it need one connection per entry within a single Jar?
Could it be something else that we are using (creating too many JARClassLoaders for
We dont do anything like that. We don't make classloaders or what every.We only do this in the markup cache checker for urls: URLConnection urlConnection = null; try {
urlConnection = url.openConnection();// update the last modified time.long lastModified =
Why??You can't call or shouldn't call it anyway...so whats the point.On 2/19/06, Gili [EMAIL PROTECTED]
wrote:I'm -1 on this.GiliJohan Compagner wrote:
+1 calling configure youre self doesn't make anysense. This is one thing that just have to be configured somewhere else (web.xml or system
On Feb 18, 2006, at 11:58 PM, Igor Vaynberg wrote:seems there is a problem with how application.configure() works.if you call configure("deployment") from application.init() it doesnt really help, because a webapp.internalinit() runs before and already called configure("development") (if you did
Well, it does in Red Hat Linux, tested with 7.3 currently, going to test with Fedora Core 4 once installed. This is only in DEVELOPMENT mode though, and it doesn't seem to show in the same way using lsof.On Feb 19, 2006, at 11:56 AM, Jesse Sightler wrote:That seems EXTREMELY unlikely. If this
It should be easy enough to write a test case to see how loading
resources behave shouldn't it? It sounds a bit wild to me too that
file pointers are being kept for every resource in a jar. Sounds very
unhealthy indeed.
Eelco
---
This SF.net
I'd expect to be able to stick all my configuration stuff in init().
Why is it alright to move configure() into XML configuration and leave
the rest of the settings in init()? All I'm saying is that there should
be consistency.
Is there no way for us to make configure() work in init()? I
because in this situation it makes sense to have this particular setting configued externally outside of code so that you can deploy your app and not have to recompile it just because now you are running in production!
-IgorOn 2/19/06, Gili [EMAIL PROTECTED] wrote:
I'd expect to be able to stick
well, lsof for me was reporting fluctuation between 1000 file
handles, and 25000 file handles every minute or so ... its probably
that the file handles were on the way to closing, when another one
opened to check it out.
this is on on older version of linux, 7.3, which may have something
Hmm,
The setting could also come from a JNDI lookup, or some other
programmatic way. Perhaps we should take that into account as well.
Martijn
On 2/19/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
because in this situation it makes sense to have this particular setting
configued externally
fine, lets just have an overriddable String getDeploymentMode() on the app. that will solve the current issue and allow the user to fetch that value from anywhere. by default we can try a sys prop and servlet init param/context param whatever.
does that sound ok?-IgorOn 2/19/06, Martijn Dashorst
OK, I surender, it's one oclock in the morningm and I have to go to work in 6 hours, I will try to do it in some other way :(, I still need to learn more, kinda hoped this work.To all thanks.Regards, Ali
On 2/19/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Hmm,The setting could also come from a
fine by meOn 2/19/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
fine, lets just have an overriddable String getDeploymentMode() on the app. that will solve the current issue and allow the user to fetch that value from anywhere. by default we can try a sys prop and servlet init param/context param
What is the difference between using configure(DEVELOPMENT) and
invoking the following code manually in init()?
getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND);
getDebugSettings().setComponentUseCheck(true);
Sounds good to me.
Gili
Igor Vaynberg wrote:
fine, lets just have an overriddable String getDeploymentMode() on the
app. that will solve the current issue and allow the user to fetch that
value from anywhere. by default we can try a sys prop and servlet init
param/context param
heh, as always you are arguing something without trying to understading the problem! please read my initial posting to this thread to see what the problem is.-IgorOn 2/19/06,
Gili [EMAIL PROTECTED] wrote:
What is the difference between using configure(DEVELOPMENT) andinvoking the following code
We can't start the resource polling thread /after/ the init method? Or
am I way out of the box here?
Martijn
On 2/19/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
fine, lets just have an overriddable String getDeploymentMode() on the app.
that will solve the current issue and allow the user to
the polling thread is not started in configure.It is started then the first markup is being loaded.So you can override the polling frequenty in youre init method again if you want to
On 2/19/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
We can't start the resource polling thread /after/ the init
That sounds pretty crazy. Did you turn off template reloading? That
would be the first thing to try, and actually wize in a production
environment anyway. /If/ that helps, we might have something that
should be done differently there.
Eelco
On 2/18/06, Andrew Lombardi [EMAIL PROTECTED] wrote:
Still, does the polling have that effect?
On 2/18/06, Andrew Lombardi [EMAIL PROTECTED] wrote:
Yeah, I agree. I found the problem, in 1.2 versions, the servlet
variable has been changed to configuration:deployment/development
instead of deployment:true/false.
So I was checking in my base
seems there is a problem with how application.configure() works.if you call configure(deployment) from application.init() it doesnt really help, because a webapp.internalinit() runs before and already called configure(development) (if you did not speicfy deployment through
web.xml or system prop)
52 matches
Mail list logo
