subject:"Re\: \[Wicket\-user\] Too many open files"

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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Jean-Baptiste Quenot

* 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  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.
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

 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
different way: I'd like Wicket to operate in production mode unless
explicitly configured to operate in development mode.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Martijn Dashorst

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 is it?

If you have to explicitly set it, what prevents you from deploying it
to production anyway?

We could add to the quickstart project's pom a filter that alters the
mode from development to deployment when a war is built.

Martijn

-- 
a href=http://www.thebeststuffintheworld.com/vote_for/wicket;Vote/a
for a href=http://www.thebeststuffintheworld.com/stuff/wicket;Wicket/a
at the a href=http://www.thebeststuffintheworld.com/;Best Stuff in
the World!/a

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

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: development and deployment. It is not that hard to
 comprehend is it?

No, no-one actually needs reloading from the jar. Reloading as it
works for most people is done via another connection. And we can test
on what kind of connection it is.

 If you have to explicitly set it, what prevents you from deploying it
 to production anyway?

 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.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Martijn Dashorst

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 restart everytime you have altered a HTML,
css, js, or properties file. Another thing is that you loose any
debugging tools you have installed. Deployment is only needed when you
package into a war. The quickstart is mainly used for development, and
therefore it is very reasonable to make the default development, until
you package your application.

Making this seamless in the building procedure is something that we
can do, but hampering development just because of plain stupidity is
not something I would like to enforce. If you enforce deployment as a
default people will go around it, ask questions on the list and look
at other frameworks because we don't have an easy development mode.

So the proposal is: set development mode in the web.xml for
quickstart. If *no* mode is set, then the default will be deployment.
When the application is packaged for war, using maven (or ant?) then
we will filter the property and make it deployment.

This way we cover the basics: development from the IDE is still
development, and building the package (WAR) will choose deployment as
a default.

Martijn

-- 
a href=http://www.thebeststuffintheworld.com/vote_for/wicket;Vote/a
for a href=http://www.thebeststuffintheworld.com/stuff/wicket;Wicket/a
at the a href=http://www.thebeststuffintheworld.com/;Best Stuff in
the World!/a

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

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 makes so much
  more sense to me.

 Because then you have to restart everytime you have altered a HTML,
 css, js, or properties file.

No, because when you're developing, you turn on the development
version, e.g. by providing a system arg when starting up or putting in
that web-xml parameter.

 Another thing is that you loose any
 debugging tools you have installed.

They should be used for development only. If you want to run your site
in development mode, that's fine, but let's just not make it a
default.

 Deployment is only needed when you
 package into a war. The quickstart is mainly used for development, and
 therefore it is very reasonable to make the default development, until
 you package your application.

The quickstart thing: that's fine, I don't care what you do with that.
I'm talking about the fact that Wicket itself by default runs in
development mode, which is just a bad idea (like I've argued before).

 Making this seamless in the building procedure is something that we
 can do, but hampering development just because of plain stupidity is
 not something I would like to enforce. If you enforce deployment as a
 default people will go around it, ask questions on the list and look
 at other frameworks because we don't have an easy development mode.

Well, now people have problems when they actually deploy! I rather
have them look a bit harder when they develop.

 So the proposal is: set development mode in the web.xml for
 quickstart. If *no* mode is set, then the default will be deployment.

Yes. If nothing is set explicitly, Wicket defaults to deployment mode.
And I don't care about what is done with the quickstart project. That
is probably used for just some testing and learning, so defaulting to
development sounds fine to me.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Flemming Boller


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 PROTECTED] wrote:


 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
different way: I'd like Wicket to operate in production mode unless
explicitly configured to operate in development mode.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Flemming Boller


I would gladly added this information to the wiki pages if you can help me
point me out which section would be a good place to add it.

/Flemming

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.

Flemming Boller wrote:
 I am glad to help you :-)

 On 11/27/06, *Nino Wael* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 I take the part about error pages back! Seems to be working. What a
 glorious day J






 *From:* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED]
 mailto:[EMAIL 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 it on the
 way because, our NICE error pages aren't shown in DEPLOYMENT mode.



 THANKS, this fixes our trouble with too many files open(at least on
 my local machine, haven't tested it on the server yet)!



 Althought now, our Error pages aren't show. However that's not for
 this thread.





 THANKS AGAIN.



 Regards Nino






 *From:* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]] *On Behalf Of
 *Flemming Boller
 *Sent:* 27. november 2006 14:12
 * To:* wicket-user@lists.sourceforge.net
 mailto:wicket-user@lists.sourceforge.net
 *Subject: * Re: [Wicket-user] Too many open files



 Hi Nino



 I also have this feature with open files, but found in a earlier
 post that it could be fixed with putting Wicket into PRODUCTION
 configuration. Either in web.xml or in the code.



 Have you tried this?





 /Flemming



 On 11/27/06, *Nino Wael*  [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Ok, that helps a bit. But where in server.xml should I write the
lines?



 Should I add a specific context for my wicket application eg like:



 Context path=/wicketAPP docBase=wicketAPP debug=0
 antiResourceLocking=1 antiJarLocking=1 /



 And if I take it from my web.xml as stated below:



 Context path=/viewer docBase=viewer debug=0
 antiResourceLocking=1 antiJarLocking=1 /





 Or are there a general switch?





 Regards Nino






 *From:* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]] *On Behalf Of
 *Johan Compagner
 *Sent:* 27. november 2006 12:24
 * To:* wicket-user@lists.sourceforge.net
 mailto:wicket-user@lists.sourceforge.net
 * Subject:* Re: [Wicket-user] Too many open files



 that is the web.xml
 you should configure it in the server.xml (see the url i sent in
 that information about the server.xml configuration)

 On 11/27/06, *Nino Wael * [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Hi Johan or others able to answer.



 How do I encorporate this, into the web.xml, where should I place it
 in the below xml? Sorry for such a novice question..





 ? xml version = 1.0 encoding = UTF-8 ?

 ! DOCTYPE web-app

   PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3
//EN

   http://java.sun.com/dtd/web-app_2_3.dtd; 



  web-app 

!-- Context parameter that specifies the local SAS
 Foundation Services metadata source properties file. --

 context-param 

param-name  local.sas.foundation.services
 / param-name 

param-value 
 /conf/sas_metadata_source_omr_testsrv.properties / param-value 

/ context-param 



!-- Declare ServletContextListener to deploy and destroy
 local SAS Foundation Services --

 listener 

listener-class 

com.sas.jobindsats.businesslogic.biplatform.FoundationServicesContextListener
 / listener-class 

/ listener 



!--F� lgende klasse h� ndterer at der bliver etableret
 en SessionContext for brugeren, n� r de kontakter webapplikationen
--

 listener 

listener-class 
 com.sas.jobindsats.businesslogic.JobindsatsBruger / listener-class


/ listener 

!--f� lgende er en versions information Servlet --

 servlet 

servlet-name  VersionInfo / servlet-name 

servlet-class

Re: [Wicket-user] Too many open files

 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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Flemming Boller


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 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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

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 an issue?

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-27 Thread Johan Compagner


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
folks!!!
But what sebastiaan in another thread proposed seems to work, i will
implement that the coming days

johan


On 11/27/06, Eelco Hillenius [EMAIL PROTECTED] wrote:


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 makes so much
  more sense to me.

 Because then you have to restart everytime you have altered a HTML,
 css, js, or properties file.

No, because when you're developing, you turn on the development
version, e.g. by providing a system arg when starting up or putting in
that web-xml parameter.

 Another thing is that you loose any
 debugging tools you have installed.

They should be used for development only. If you want to run your site
in development mode, that's fine, but let's just not make it a
default.

 Deployment is only needed when you
 package into a war. The quickstart is mainly used for development, and
 therefore it is very reasonable to make the default development, until
 you package your application.

The quickstart thing: that's fine, I don't care what you do with that.
I'm talking about the fact that Wicket itself by default runs in
development mode, which is just a bad idea (like I've argued before).

 Making this seamless in the building procedure is something that we
 can do, but hampering development just because of plain stupidity is
 not something I would like to enforce. If you enforce deployment as a
 default people will go around it, ask questions on the list and look
 at other frameworks because we don't have an easy development mode.

Well, now people have problems when they actually deploy! I rather
have them look a bit harder when they develop.

 So the proposal is: set development mode in the web.xml for
 quickstart. If *no* mode is set, then the default will be deployment.

Yes. If nothing is set explicitly, Wicket defaults to deployment mode.
And I don't care about what is done with the quickstart project. That
is probably used for just some testing and learning, so defaulting to
development sounds fine to me.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-13 Thread Johan Compagner

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 as well Nagios on the same machinewe come across Too many open files problem.We are using soft limit of 4096 and hard limit of 63536.However, we are monitoring the number of file handles open and it is
gradually increasing.The files - /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar arebeing opened repeatedly.Eventually we see the following problem and the web server is stuck.
Any ideas?2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOExceptionwhile saving persisted sessions: java.io.FileNotFoundException:/opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
(Too many open files) java.io.FileNotFoundException:/opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser(Too many open files)at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)at java.io.FileOutputStream.init(FileOutputStream.java:70)atorg.apache.catalina.session.StandardManager.doUnload
(StandardManager.java:488)atorg.apache.catalina.session.StandardManager.unload(StandardManager.java:462)atorg.apache.catalina.session.StandardManager.stop(StandardManager.java:666)
atorg.apache.catalina.core.StandardContext.stop(StandardContext.java:4337)atorg.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892)atorg.apache.catalina.startup.HostConfig.undeployApps
(HostConfig.java:1153)at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125)atorg.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312)at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)atorg.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1054)atorg.apache.catalina.core.ContainerBase.stop
(ContainerBase.java:1066)atorg.apache.catalina.core.StandardEngine.stop(StandardEngine.java:447)atorg.apache.catalina.core.StandardService.stop(StandardService.java:512)at
org.apache.catalina.core.StandardServer.stop(StandardServer.java:743)at org.apache.catalina.startup.Catalina.stop(Catalina.java:601)atorg.apache.catalina.startup.Catalina$CatalinaShutdownHook.run
(Catalina.java:644)-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-13 Thread Eelco Hillenius

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:

 http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Standard%20Implementation

 johan

 On 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 limit of 4096 and hard limit of 63536.
  However, we are monitoring the number of file handles open and it is
  gradually increasing.
 
 
  The files -
 /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar 
 
 /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar
 are
  being opened repeatedly.
 
  Eventually we see the following problem and the web server is stuck.
 
  Any ideas?
 
 
  2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOException
  while saving persisted sessions: java.io.FileNotFoundException:
 
 /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
  (Too many open files)
 
  java.io.FileNotFoundException:
 
 /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
  (Too many open files)
 
  at java.io.FileOutputStream.open(Native Method)
 
  at java.io.FileOutputStream.init(FileOutputStream.java:179)
 
  at java.io.FileOutputStream.init(FileOutputStream.java:70)
 
  at
  org.apache.catalina.session.StandardManager.doUnload
 (StandardManager.java:488)
 
  at
 
 org.apache.catalina.session.StandardManager.unload(StandardManager.java:462)
 
  at
 
 org.apache.catalina.session.StandardManager.stop(StandardManager.java:666)
 
  at
 
 org.apache.catalina.core.StandardContext.stop(StandardContext.java:4337)
 
  at
 
 org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892)
 
  at
  org.apache.catalina.startup.HostConfig.undeployApps
 (HostConfig.java:1153)
 
  at
 org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125)
 
  at
 
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312)
 
  at
 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 
  at
 
 org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1054)
 
  at
  org.apache.catalina.core.ContainerBase.stop
 (ContainerBase.java:1066)
 
  at
 
 org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:447)
 
  at
 
 org.apache.catalina.core.StandardService.stop(StandardService.java:512)
 
  at
 
 org.apache.catalina.core.StandardServer.stop(StandardServer.java:743)
 
  at
 org.apache.catalina.startup.Catalina.stop(Catalina.java:601)
 
  at
 
 org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run
 (Catalina.java:644)
 
 
 
 
 -
  Using Tomcat but need to do more? Need to support web services, security?
  Get stuff done quickly with pre-integrated technology to make your job
 easier
  Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job
 easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642

 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user




-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-13 Thread Johan Compagner

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 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 Adoram 
[EMAIL PROTECTED] wrote:
This solves the problem of course.However, why does the ModificationWatcher look for modified resourceswithin wicket jars?If component A extends component B, the MarkupCache should indeed verifywatch B as well unless it is a wicket component.
Why would anyone replace markup inside a wicket jar?Eelco Hillenius wrote: 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, though
 we solved enough issues to upgrade to the latest anyway :) Eelco On 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 limit of 4096 and hard limit of 63536.
 However, we are monitoring the number of file handles open and it is gradually increasing. The files - /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar 

 /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar are being opened repeatedly. Eventually we see the following problem and the web server is stuck.
 Any ideas? 2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOException while saving persisted sessions: java.io.FileNotFoundException: /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
 (Too many open files)java.io.FileNotFoundException: /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser (Too many open files)

 at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream

.init(FileOutputStream.java:70) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:488) at org.apache.catalina.session.StandardManager.unload

(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666) at org.apache.catalina.core.StandardContext.stop

(StandardContext.java:4337) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892) at org.apache.catalina.startup.HostConfig.undeployApps

(HostConfig.java:1153) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125) at org.apache.catalina.startup.HostConfig.lifecycleEvent

(HostConfig.java:312) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.stop

(ContainerBase.java:1054) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1066) at org.apache.catalina.core.StandardEngine.stop

(StandardEngine.java:447) at org.apache.catalina.core.StandardService.stop(StandardService.java:512) at org.apache.catalina.core.StandardServer.stop

(StandardServer.java:743) at org.apache.catalina.startup.Catalina.stop(Catalina.java:601) at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run

(Catalina.java:644) - Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo 

http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list 

Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
 -
 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1

 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642

 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
 
https://lists.sourceforge.net/lists/listinfo/wicket-user-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

Re: [Wicket-user] Too many open files

2006-11-13 Thread Johan Compagner

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 Adoram [EMAIL PROTECTED] wrote:
This solves the problem of course.However, why does the ModificationWatcher look for modified resourceswithin wicket jars?If component A extends component B, the MarkupCache should indeed verifywatch B as well unless it is a wicket component.
Why would anyone replace markup inside a wicket jar?Eelco Hillenius wrote: 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, though
 we solved enough issues to upgrade to the latest anyway :) Eelco On 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 limit of 4096 and hard limit of 63536.
 However, we are monitoring the number of file handles open and it is gradually increasing. The files - /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar 
 /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar are being opened repeatedly. Eventually we see the following problem and the web server is stuck.
 Any ideas? 2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOException while saving persisted sessions: java.io.FileNotFoundException: /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
 (Too many open files)java.io.FileNotFoundException: /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser (Too many open files)
 at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream
.init(FileOutputStream.java:70) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:488) at org.apache.catalina.session.StandardManager.unload
(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666) at org.apache.catalina.core.StandardContext.stop
(StandardContext.java:4337) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892) at org.apache.catalina.startup.HostConfig.undeployApps
(HostConfig.java:1153) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125) at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:312) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.stop
(ContainerBase.java:1054) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1066) at org.apache.catalina.core.StandardEngine.stop
(StandardEngine.java:447) at org.apache.catalina.core.StandardService.stop(StandardService.java:512) at org.apache.catalina.core.StandardServer.stop
(StandardServer.java:743) at org.apache.catalina.startup.Catalina.stop(Catalina.java:601) at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run
(Catalina.java:644) - Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo 
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Wicket-user mailing list 
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user -
 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1
 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/wicket-user-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need

Re: [Wicket-user] Too many open files

2006-11-13 Thread Nili Adoram

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 jar?


Eelco Hillenius wrote:
 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, though
 we solved enough issues to upgrade to the latest anyway :)

 Eelco



 On 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 limit of 4096 and hard limit of 63536.
 However, we are monitoring the number of file handles open and it is
 gradually increasing.


 The files - /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar 
 /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar are
 being opened repeatedly.

 Eventually we see the following problem and the web server is stuck.

 Any ideas?


 2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOException
 while saving persisted sessions: java.io.FileNotFoundException:
 /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
 (Too many open files)

  java.io.FileNotFoundException:
 /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
 (Too many open files)

 at java.io.FileOutputStream.open(Native Method)

 at java.io.FileOutputStream.init(FileOutputStream.java:179)

 at java.io.FileOutputStream.init(FileOutputStream.java:70)

 at
 org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:488)

 at
 org.apache.catalina.session.StandardManager.unload(StandardManager.java:462)

 at
 org.apache.catalina.session.StandardManager.stop(StandardManager.java:666)

 at
 org.apache.catalina.core.StandardContext.stop(StandardContext.java:4337)

 at
 org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892)

 at
 org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1153)

 at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125)

 at
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312)

 at
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)

 at
 org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1054)

 at
 org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1066)

 at
 org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:447)

 at
 org.apache.catalina.core.StandardService.stop(StandardService.java:512)

 at
 org.apache.catalina.core.StandardServer.stop(StandardServer.java:743)

 at org.apache.catalina.startup.Catalina.stop(Catalina.java:601)

 at
 org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:644)



 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

 

 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

   

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-12 Thread Frank Bille

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 limit of 4096 and hard limit of 63536.However, we are monitoring the number of file handles open and it isgradually increasing.
The files - /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar arebeing opened repeatedly.Eventually we see the following problem and the web server is stuck.
Any ideas?2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOExceptionwhile saving persisted sessions: java.io.FileNotFoundException:/opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
(Too many open files) java.io.FileNotFoundException:/opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser(Too many open files)at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:179)at java.io.FileOutputStream.init(FileOutputStream.java:70)atorg.apache.catalina.session.StandardManager.doUnload
(StandardManager.java:488)atorg.apache.catalina.session.StandardManager.unload(StandardManager.java:462)atorg.apache.catalina.session.StandardManager.stop(StandardManager.java:666)
atorg.apache.catalina.core.StandardContext.stop(StandardContext.java:4337)atorg.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892)atorg.apache.catalina.startup.HostConfig.undeployApps
(HostConfig.java:1153)at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125)atorg.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312)at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)atorg.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1054)atorg.apache.catalina.core.ContainerBase.stop
(ContainerBase.java:1066)atorg.apache.catalina.core.StandardEngine.stop(StandardEngine.java:447)atorg.apache.catalina.core.StandardService.stop(StandardService.java:512)at
org.apache.catalina.core.StandardServer.stop(StandardServer.java:743)at org.apache.catalina.startup.Catalina.stop(Catalina.java:601)atorg.apache.catalina.startup.Catalina$CatalinaShutdownHook.run
(Catalina.java:644)-Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files

2006-11-12 Thread Eelco Hillenius

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, though
we solved enough issues to upgrade to the latest anyway :)

Eelco



On 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 limit of 4096 and hard limit of 63536.
 However, we are monitoring the number of file handles open and it is
 gradually increasing.


 The files - /opt/qrm/java/webapp/WEB-INF/lib/wicket-1.2.2.jar 
 /opt/qrm/java/webapp/WEB-INF/lib/wicket-extensions-1.2.2-patch.jar are
 being opened repeatedly.

 Eventually we see the following problem and the web server is stuck.

 Any ideas?


 2006-11-08 19:42:22,104 ERROR [ManagerBase] (Thread-29:) IOException
 while saving persisted sessions: java.io.FileNotFoundException:
 /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
 (Too many open files)

  java.io.FileNotFoundException:
 /opt/qrm/usr/tomcat/work/Catalina/localhost/host-manager/SESSIONS.ser
 (Too many open files)

 at java.io.FileOutputStream.open(Native Method)

 at java.io.FileOutputStream.init(FileOutputStream.java:179)

 at java.io.FileOutputStream.init(FileOutputStream.java:70)

 at
 org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:488)

 at
 org.apache.catalina.session.StandardManager.unload(StandardManager.java:462)

 at
 org.apache.catalina.session.StandardManager.stop(StandardManager.java:666)

 at
 org.apache.catalina.core.StandardContext.stop(StandardContext.java:4337)

 at
 org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:892)

 at
 org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1153)

 at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1125)

 at
 org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312)

 at
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)

 at
 org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1054)

 at
 org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1066)

 at
 org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:447)

 at
 org.apache.catalina.core.StandardService.stop(StandardService.java:512)

 at
 org.apache.catalina.core.StandardServer.stop(StandardServer.java:743)

 at org.apache.catalina.startup.Catalina.stop(Catalina.java:601)

 at
 org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:644)



 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-24 Thread Martijn Dashorst

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 2/20/06, Johan Compagner [EMAIL PROTECTED] wrote:
 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 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 fetch that value
   from anywhere. by default we can try a sys prop and servlet init
   param/context param whatever.
  
   does that sound ok?
  
   -Igor
  
  
  
   On 2/19/06, Martijn Dashorst [EMAIL PROTECTED]  wrote:
   
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 outside of code so that you can deploy your app
 and
   not
 have to recompile it just because now you are running in production!

 -Igor


 On 2/19/06, Gili  [EMAIL PROTECTED] wrote:
 
  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
 understand
  it is more work than simply removing configure(), but in my view
   that's
  like fixing a bug by removing the feature. Just my 2 cents...
 
  Gili
 
  Andrew Lombardi wrote:
   +1 on this.  To make the programmatic configure() work just
 seems
   like a
   lot of fluff, don't see why you'd ever need to call this during
 the
   app's lifecycle, only at the beginning.
 
 
 
 
   ---
  This SF.net email is sponsored by: Splunk Inc. Do you grep through
 log
 files
  for problems?  Stop!  Download the new AJAX search engine that
 makes
  searching your log files as easy as surfing the  web.  DOWNLOAD
   SPLUNK!
 

  
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 
  
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 


   
   
--
Living a wicket life...
   
Martijn Dashorst -
 http://www.jroller.com/page/dashorst
   
Wicket 1.1.1 is out:
   http://wicket.sourceforge.net/wicket-1.1
   
   
   
 ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
   files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD
 SPLUNK!
   
  
 http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
 
 
  --
  Living a wicket life...
 
  Martijn Dashorst - http://www.jroller.com/page/dashorst
 
  Wicket 1.1.1 is out:
 http://wicket.sourceforge.net/wicket-1.1
 
 
  ---
  This SF.net email is sponsored by: Splunk Inc. Do you grep through log
 files
  for problems?  Stop!  Download the new AJAX search engine that makes
  searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
 
 http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 




--
Living a wicket life...

Martijn Dashorst - http://www.jroller.com/page/dashorst

Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!

Re: [Wicket-user] Too many open files problem



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 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) and so the resource thread is started 
already.


my thought on this would be to get rid of public configure(string) 
methods and let deployment mode be configured either from web.xml or a 
system prop.


and yes, turning off that thread solves andrew's problem.

-Igor




On 2/18/06, *Eelco Hillenius*  [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Still, does the polling have that effect?

On 2/18/06, Andrew Lombardi [EMAIL PROTECTED]
mailto:[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 application class for deployment servlet
  var, and calling configure(deployment) .. wasn't helping though
  since the poll frequency was already set internally when
  configuration variable is not found, so assumed development mode.  So
  it was polling every 1 second, even though I had set configure
  (deployment)
 
  Doh!
 
 
  On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:
 
   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]
mailto:[EMAIL PROTECTED] wrote:
   When deploying one of our wicket-developed applications to our
   production linux server, we've been seeing something very odd,
maybe
   someone can shed some light.  This morning I awoke to error
messages
   in our Resin app server logs about Too many open
files.  Checking
   the max value, it was set at 65000.
  
   A check using lsof showed that the jar file where I have the Page
   classes/html/prop files, had several entries.  And it would
vary up
   and down from 1000 to well over 15000 entries for that single
jar.
   I'm in the process of setting up a test environment to see if
I can
   recreate the issue locally, or if it might be a linux-based issue.
   I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest
   snapshot from Wicket 1.2 branch.
  
   Any ideas?
  
  
  
   ---
   This SF.net email is sponsored by: Splunk Inc. Do you grep through
   log files
   for problems?  Stop!  Download the new AJAX search engine that
makes
   searching your log files as easy as surfing the  web.  DOWNLOAD
   SPLUNK!
   http://sel.as-us.falkag.net/sel?
   cmd=lnkkid=103432bid=230486dat=121642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
   ---
   This SF.net email is sponsored by: Splunk Inc. Do you grep through
   log files
   for problems?  Stop!  Download the new AJAX search engine that
makes
   searching your log files as easy as surfing the  web.  DOWNLOAD
   SPLUNK!
   http://sel.as-us.falkag.net/sel?
   cmd___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
  ---
  This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
  for problems?  Stop!  Download the new AJAX search engine that makes
  searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
 
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

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 problems with it because we have many resources.Maybe we can make the polling smarter.. If the resources comes from a jar file then don't test it anymore.
But don't know if we can see that (its the instance of the url connection that specifies that i guess)johanOn 2/19/06, Gili
[EMAIL PROTECTED] wrote: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?GiliIgor 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 not speicfy deployment through web.xml or system prop) and so the resource thread is started
already. my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from web.xml or a system prop. and yes, turning off that thread solves andrew's problem.
-Igor On 2/18/06, *Eelco Hillenius* [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED] wrote: Still, does the polling have that effect? On 2/18/06, Andrew Lombardi [EMAIL PROTECTED]
mailto:[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 application class for deployment servlet var, and calling configure(deployment) .. wasn't helping though
since the poll frequency was already set internally when configuration variable is not found, so assumed development mode.So it was polling every 1 second, even though I had set configure
(deployment) Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote: 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.
EelcoOn 2/18/06, Andrew Lombardi [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote: When deploying one of our wicket-developed applications to our production linux server, we've been seeing something very odd,
maybe someone can shed some light.This morning I awoke to error messages in our Resin app server logs about Too many open files.Checking
the max value, it was set at 65000. A check using lsof showed that the jar file where I have the Page classes/html/prop files, had several entries.And it would
vary up and down from 1000 to well over 15000 entries for that single jar. I'm in the process of setting up a test environment to see if I can
recreate the issue locally, or if it might be a linux-based issue. I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest snapshot from Wicket
1.2 branch. Any ideas? ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that
makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel
? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?
cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

+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 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) and so the resource thread is started already.my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from web.xml or a system prop.
and yes, turning off that thread solves andrew's problem.-IgorOn 2/18/06,
Eelco Hillenius
[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 application class for deployment servlet var, and calling configure(deployment) .. wasn't helping though
since the poll frequency was already set internally when configuration variable is not found, so assumed development mode.So it was polling every 1 second, even though I had set configure (deployment)
Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote: 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. EelcoOn 2/18/06, Andrew Lombardi
[EMAIL PROTECTED] wrote: When deploying one of our wicket-developed applications to our
production linux server, we've been seeing something very odd, maybe
someone can shed some light.This morning I awoke to error messages in our Resin app server logs about Too many open files.Checking the max value, it was set at 65000.
A check using lsof showed that the jar file where I have the Page classes/html/prop files, had several entries.And it would vary up and down from 1000 to well over 15000 entries for that single jar.
I'm in the process of setting up a test environment to see if I can recreate the issue locally, or if it might be a linux-based issue. I'm using Resin 3.0.17 with JDK 1.5.0_06

, and using the latest snapshot from Wicket 1.2 branch. Any ideas? ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD
SPLUNK! http://sel.as-us.falkag.net/sel? cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list Wicket-user@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!

http://sel.as-us.falkag.net/sel? cmd___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___Wicket-user mailing listWicket-user@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Jesse Sightler

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 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 problems with it because we have many resources.
Maybe we can make the polling smarter.. If the resources comes from a jar file then don't test it anymore.
But don't know if we can see that (its the instance of the url connection that specifies that i guess)johan
On 2/19/06, Gili
[EMAIL PROTECTED] wrote: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?GiliIgor 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 not speicfy deployment through web.xml or system prop) and so the resource thread is started
already. my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from web.xml or a system prop. and yes, turning off that thread solves andrew's problem.
-Igor On 2/18/06, *Eelco Hillenius* [EMAIL PROTECTED]
mailto:
[EMAIL PROTECTED] wrote: Still, does the polling have that effect? On 2/18/06, Andrew Lombardi
[EMAIL PROTECTED]
mailto:[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 application class for deployment servlet var, and calling configure(deployment) .. wasn't helping though
since the poll frequency was already set internally when configuration variable is not found, so assumed development mode.So it was polling every 1 second, even though I had set configure
(deployment) Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote: 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.
EelcoOn 2/18/06, Andrew Lombardi
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote: When deploying one of our wicket-developed applications to our
production linux server, we've been seeing something very odd,
maybe someone can shed some light.This morning I awoke to error messages in our Resin app server logs about Too many open files.Checking
the max value, it was set at 65000. A check using lsof showed that the jar file where I have the Page classes/html/prop files, had several entries.And it would
vary up and down from 1000 to well over 15000 entries for that single jar. I'm in the process of setting up a test environment to see if I can
recreate the issue locally, or if it might be a linux-based issue. I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest snapshot from Wicket
1.2 branch. Any ideas? ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that
makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel
? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?
cmd___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!

http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___ Wicket-user mailing list

Re: [Wicket-user] Too many open files problem

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 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 do ONE thing about it.. It really sucks i know but its out of our hands.Here is the bug:

[EMAIL PROTECTED]
mailto:[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 application class for deployment servlet var, and calling configure(deployment) .. wasn't helping though
since the poll frequency was already set internally when configuration variable is not found, so assumed development mode.So it was polling every 1 second, even though I had set configure
(deployment) Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote: 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.
EelcoOn 2/18/06, Andrew Lombardi

[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote: When deploying one of our wicket-developed applications to our
production linux server, we've been seeing something very odd,
maybe someone can shed some light.This morning I awoke to error messages in our Resin app server logs about Too many open files.Checking
the max value, it was set at 65000. A check using lsof showed that the jar file where I have the Page classes/html/prop files, had several entries.And it would
vary up and down from 1000 to well over 15000 entries for that single jar. I'm in the process of setting up a test environment to see if I can
recreate the issue locally, or if it might be a linux-based issue. I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest snapshot from Wicket
1.2 branch. Any ideas? ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that
makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!

http://sel.as-us.falkag.net/sel
? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto:

Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!

http://sel.as-us.falkag.net/sel?
cmd___ Wicket-user mailing list

Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!

Re: [Wicket-user] Too many open files problem



	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 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=4950148

Please vote for it, because we as wicket really have problems with it 
because we have many resources.


Maybe we can make the polling smarter.. If the resources comes from a 
jar file then don't test it anymore.
But don't know if we can see that (its the instance of the url 
connection that specifies that i guess)


johan


On 2/19/06, *Gili*  [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



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 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) and so the resource thread is
started
  already.
 
  my thought on this would be to get rid of public configure(string)
  methods and let deployment mode be configured either from web.xml
or a
  system prop.
 
  and yes, turning off that thread solves andrew's problem.
 
  -Igor
 
 
 
 
  On 2/18/06, *Eelco Hillenius*  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
 
  Still, does the polling have that effect?
 
  On 2/18/06, Andrew Lombardi [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[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 application class for
deployment servlet
var, and calling configure(deployment) .. wasn't helping
though
since the poll frequency was already set internally when
configuration variable is not found, so assumed
development mode.  So
it was polling every 1 second, even though I had set
configure
(deployment)
   
Doh!
   
   
On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:
   
 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]
mailto:[EMAIL PROTECTED]
  mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
 When deploying one of our wicket-developed applications
to our
 production linux server, we've been seeing something
very odd,
  maybe
 someone can shed some light.  This morning I awoke to error
  messages
 in our Resin app server logs about Too many open
  files.  Checking
 the max value, it was set at 65000.

 A check using lsof showed that the jar file where I
have the Page
 classes/html/prop files, had several entries.  And it
would
  vary up
 and down from 1000 to well over 15000 entries for that
single
  jar.
 I'm in the process of setting up a test environment to
see if
  I can
 recreate the issue locally, or if it might be a
linux-based issue.
 I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using
the latest
 snapshot from Wicket 1.2 branch.

 Any ideas?



 ---
 This SF.net email is sponsored by: Splunk Inc. Do you
grep through
 log files
 for problems?  Stop!  Download the new AJAX search
engine that
  makes
 searching your log files as easy as surfing
the  web.  DOWNLOAD
 SPLUNK!
 http://sel.as-us.falkag.net/sel

Re: [Wicket-user] Too many open files problem



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:


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) and so the resource
thread is started already.

my thought on this would be to get rid of public configure(string)
methods and let deployment mode be configured either from web.xml or
a system prop.

and yes, turning off that thread solves andrew's problem.

-Igor





On 2/18/06, * Eelco Hillenius*  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

Still, does the polling have that effect?

On 2/18/06, Andrew Lombardi [EMAIL PROTECTED]
mailto:[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 application class for deployment
servlet
  var, and calling configure(deployment) .. wasn't helping though
  since the poll frequency was already set internally when
  configuration variable is not found, so assumed development
mode.  So
  it was polling every 1 second, even though I had set configure
  (deployment)

  Doh!


  On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:

   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]
mailto:[EMAIL PROTECTED] wrote:
   When deploying one of our wicket-developed applications to our
   production linux server, we've been seeing something very
odd, maybe
   someone can shed some light.  This morning I awoke to error
messages
   in our Resin app server logs about Too many open
files.  Checking
   the max value, it was set at 65000.
  
   A check using lsof showed that the jar file where I have
the Page
   classes/html/prop files, had several entries.  And it would
vary up
   and down from 1000 to well over 15000 entries for that
single jar.
   I'm in the process of setting up a test environment to see
if I can
   recreate the issue locally, or if it might be a linux-based
issue.
   I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest
   snapshot from Wicket 1.2 branch.
  
   Any ideas?
  
  
  
   ---
   This SF.net email is sponsored by: Splunk Inc. Do you grep
through
   log files
   for problems?  Stop!  Download the new AJAX search engine
that makes
   searching your log files as easy as surfing
the  web.  DOWNLOAD
   SPLUNK!
   http://sel.as-us.falkag.net/sel?
   cmd=lnkkid=103432bid=230486dat=121642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
   ---
   This SF.net email is sponsored by: Splunk Inc. Do you grep
through
   log files
   for problems?  Stop!  Download the new AJAX search engine
that makes
   searching your log files as easy as surfing the  web.  DOWNLOAD
   SPLUNK!
   http://sel.as-us.falkag.net/sel?
   cmd___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user



  ---
  This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
  for problems?  Stop!  Download the new AJAX

Re: [Wicket-user] Too many open files problem

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,
Jesse Sightler [EMAIL PROTECTED] wrote:

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://sel.as-us.falkag.net/sel
? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto:

http://sel.as-us.falkag.net/sel?
cmd___ Wicket-user mailing list

Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Jesse Sightler

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 the same jar or something)?-- JessOn 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.johan
On 2/19/06,
Jesse Sightler [EMAIL PROTECTED] wrote:

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://sel.as-us.falkag.net/sel
? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto:

http://sel.as-us.falkag.net/sel?
cmd___ Wicket-user mailing list

Wicket-user@lists.sourceforge.net

Re: [Wicket-user] Too many open files problem

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 = urlConnection.getLastModified();if (lastModified != 
this.lastModified){ this.lastModified = lastModified; this.contentLength = urlConnection.getContentLength();}   }   catch (IOException e)
   {log.error(getLastModified for  + url +  failed:  + e.getMessage());   }   finally   {// if applicable, disconnect
if (urlConnection != null){ if (urlConnection instanceof HttpURLConnection) {  ((HttpURLConnection)urlConnection).disconnect();
 } else {  try  {   urlConnection.getInputStream().close();  }
  catch (Exception ex)  {   // ignore  } }}   }Ad you can see we do everything in our power to close everything .
The problem is that that disconnect() method is only there for http resources.Why you can have a Connection object without the possibility to close it is beyond me..The stupid thing is if you look at the source code of all the JarXXX classes 
There are plenty of close and cleanup methods. We just can access them..johanOn 2/19/06, Jesse Sightler 
[EMAIL PROTECTED] wrote: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 the same jar or something)?-- Jess
On 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.johan
On 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 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 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 problems with it because we have many resources.
Maybe we can make the polling smarter.. If the resources comes from a jar file then don't test it anymore.
But don't know if we can see that (its the instance of the url connection that specifies that i guess)johan
On 2/19/06, Gili 
[EMAIL PROTECTED] wrote: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?GiliIgor 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 not speicfy deployment through web.xml or system prop) and so the resource thread is started
 already. my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from web.xml or a system prop. and yes, turning off that thread solves andrew's problem.
 -Igor On 2/18/06, *Eelco Hillenius*  [EMAIL PROTECTED]
 mailto:
[EMAIL PROTECTED] wrote: Still, does the polling have that effect? On 2/18/06, Andrew Lombardi 



[EMAIL PROTECTED]
 mailto:[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 application class for deployment servlet var, and calling configure(deployment) .. wasn't helping though
 since the poll frequency was already set internally when configuration variable is not found, so assumed development mode.So it was polling every 1 second, even though I had set configure
 (deployment) Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:  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.
   EelcoOn 2/18/06, Andrew Lombardi  



[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:  When deploying one of our wicket-developed applications to our
  production linux server, we've been seeing something very odd,
 maybe  someone can shed some light.This morning I awoke to error messages  in our Resin app server logs about Too many open files.Checking
  the max value, it was set at 65000.   A check using lsof showed that the jar file where I have the Page  classes/html/prop

Re: [Wicket-user] Too many open files problem

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 property) johan On 2/19/06, * Igor Vaynberg*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 not speicfy
deployment through web.xml or system prop) and so the resource thread is started already. my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from
web.xml or a system prop. and yes, turning off that thread solves andrew's problem. -Igor On 2/18/06, * Eelco Hillenius*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Still, does the polling have that effect?
On 2/18/06, Andrew Lombardi [EMAIL PROTECTED] mailto:[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 application class for deployment servlet var, and calling configure(deployment) .. wasn't helping though
since the poll frequency was already set internally when configuration variable is not found, so assumed development mode.So it was polling every 1 second, even though I had set configure
(deployment) Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:
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] mailto:
[EMAIL PROTECTED] wrote: When deploying one of our wicket-developed applications to our production linux server, we've been seeing something very
odd, maybe someone can shed some light.This morning I awoke to error messages in our Resin app server logs about Too many open
files.Checking the max value, it was set at 65000. A check using lsof showed that the jar file where I have
the Page classes/html/prop files, had several entries.And it would vary up and down from 1000 to well over 15000 entries for that
single jar. I'm in the process of setting up a test environment to see if I can recreate the issue locally, or if it might be a linux-based
issue. I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest snapshot from Wicket 1.2 branch. Any ideas?
--- This SF.net
email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD
SPLUNK! http://sel.as-us.falkag.net/sel? cmd___
Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___
Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
http://sel.as-us.falkag.net/sel?cmdlnkkid%103432bid#0486dat%121642

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Andrew Lombardi

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 not speicfy deployment through web.xml or system prop) and so the resource thread is started already.my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from web.xml or a system prop. +1 on this. To make the programmatic configure() work just seems like a lot of fluff, don't see why you'd ever need to call this during the app's lifecycle, only at the beginning.and yes, turning off that thread solves andrew's problem.-IgorOn 2/18/06, Eelco Hillenius [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 application class for deployment servlet var, and calling configure("deployment") .. wasn't helping though since the poll frequency was already set internally when configuration variable is not found, so assumed development mode. So it was polling every 1 second, even though I had set configure ("deployment") Doh! On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote: 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. EelcoOn 2/18/06, Andrew Lombardi [EMAIL PROTECTED] wrote: When deploying one of our wicket-developed applications to our production linux server, we've been seeing something very odd, maybe someone can shed some light. This morning I awoke to error messages in our Resin app server logs about "Too many open files". Checking the max value, it was set at 65000.A check using lsof showed that the jar file where I have the Page classes/html/prop files, had several entries. And it would vary up and down from 1000 to well over 15000 entries for that single jar. I'm in the process of setting up a test environment to see if I can recreate the issue locally, or if it might be a linux-based issue. I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest snapshot from Wicket 1.2 branch. Any ideas? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel? cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel? cmd___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user ---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Andrew Lombardi

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 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 the same jar or something)?-- JessOn 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.johan On 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 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 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 problems with it because we have many resources. Maybe we can make the polling smarter.. If the resources comes from a jar file then don't test it anymore. But don't know if we can see that (its the instance of the url connection that specifies that i guess)johan On 2/19/06, Gili  [EMAIL PROTECTED] wrote: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?GiliIgor 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 not speicfy deployment through web.xml or system prop) and so the resource thread is started  already. my thought on this would be to get rid of public configure(string) methods and let deployment mode be configured either from web.xml or a system prop. and yes, turning off that thread solves andrew's problem.  -Igor On 2/18/06, *Eelco Hillenius*  [EMAIL PROTECTED]  mailto: [EMAIL PROTECTED] wrote: Still, does the polling have that effect? On 2/18/06, Andrew Lombardi  [EMAIL PROTECTED]  mailto:[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 application class for deployment servlet   var, and calling configure("deployment") .. wasn't helping though    since the poll frequency was already set internally when   configuration variable is not found, so assumed development mode.  So   it was polling every 1 second, even though I had set configure    ("deployment") Doh!   On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:  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]  mailto:[EMAIL PROTECTED] wrote:    When deploying one of our wicket-developed applications to our     production linux server, we've been seeing something very odd,  maybe    someone can shed some light.  This morning I awoke to error messages    in our Resin app server logs about "Too many open files".  Checking     the max value, it was set at 65000.       A check using lsof showed that the jar file where I have the Page    classes/html/prop files, had several entries.  And it would  vary up    and down from 1000 to well over 15000 entries for that single jar.    I'm in the process of setting up a test environment to see if I can     recreate the issue locally, or if it might be a linux-based issue.    I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest    snapshot from Wicket 1.2 branch.       Any ideas?             ---     This SF.net email is sponsored by: Splunk Inc. Do you grep through    log files    for problems?  Stop!  Download the new AJAX search engine that  makes    searching your log files as easy as surfing the  web.  DOWNLOAD    SPLUNK!     http://sel.as-us.falkag.net/sel ?    cmd=lnkkid=103432bid=230486dat=121642

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Eelco Hillenius

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 email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem



	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 understand 
it is more work than simply removing configure(), but in my view that's 
like fixing a bug by removing the feature. Just my 2 cents...


Gili

Andrew Lombardi wrote:
+1 on this.  To make the programmatic configure() work just seems like a 
lot of fluff, don't see why you'd ever need to call this during the 
app's lifecycle, only at the beginning.




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

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 all my configuration stuff in init().Why is it alright to move configure() into XML configuration and leavethe 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 understandit is more work than simply removing configure(), but in my view that'slike fixing a bug by removing the feature. Just my 2 cents...
GiliAndrew Lombardi wrote: +1 on this.To make the programmatic configure() work just seems like a lot of fluff, don't see why you'd ever need to call this during the app's lifecycle, only at the beginning.
---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Andrew Lombardi

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  
to do with it.



On Feb 19, 2006, at 1:22 PM, Eelco Hillenius wrote:


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 email is sponsored by: Splunk Inc. Do you grep through  
log files

for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD  
SPLUNK!
http://sel.as-us.falkag.net/sel? 
cmd___

Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Martijn Dashorst

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 outside of code so that you can deploy your app and not
 have to recompile it just because now you are running in production!

 -Igor


 On 2/19/06, Gili [EMAIL PROTECTED] wrote:
 
  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
 understand
  it is more work than simply removing configure(), but in my view that's
  like fixing a bug by removing the feature. Just my 2 cents...
 
  Gili
 
  Andrew Lombardi wrote:
   +1 on this.  To make the programmatic configure() work just seems like a
   lot of fluff, don't see why you'd ever need to call this during the
   app's lifecycle, only at the beginning.
 
 
 
  ---
  This SF.net email is sponsored by: Splunk Inc. Do you grep through log
 files
  for problems?  Stop!  Download the new AJAX search engine that makes
  searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
 
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 




--
Living a wicket life...

Martijn Dashorst - http://www.jroller.com/page/dashorst

Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

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 [EMAIL PROTECTED]
wrote:Hmm,The setting could also come from a JNDI lookup, or some other
programmatic way. Perhaps we should take that into account as well.MartijnOn 2/19/06, Igor Vaynberg [EMAIL PROTECTED] wrote: 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! -Igor On 2/19/06, Gili
[EMAIL PROTECTED] wrote: 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 understand
it is more work than simply removing configure(), but in my view that's like fixing a bug by removing the feature. Just my 2 cents... Gili Andrew Lombardi wrote:
+1 on this.To make the programmatic configure() work just seems like a lot of fluff, don't see why you'd ever need to call this during the app's lifecycle, only at the beginning.
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user --Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Ali Zaid

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 JNDI lookup, or some otherprogrammatic way. Perhaps we should take that into account as well.MartijnOn 2/19/06, Igor Vaynberg 
[EMAIL PROTECTED] wrote: 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!
 -Igor On 2/19/06, Gili [EMAIL PROTECTED] wrote:   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 understand  it is more work than simply removing configure(), but in my view that's  like fixing a bug by removing the feature. Just my 2 cents...
   Gili   Andrew Lombardi wrote:   +1 on this.To make the programmatic configure() work just seems like a   lot of fluff, don't see why you'd ever need to call this during the
   app's lifecycle, only at the beginning. ---  This SF.net email is sponsored by: Splunk Inc. Do you grep through log
 files  for problems?Stop!Download the new AJAX search engine that makes  searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!  
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642  ___  Wicket-user mailing list  
Wicket-user@lists.sourceforge.net  https://lists.sourceforge.net/lists/listinfo/wicket-user --
Living a wicket life...Martijn Dashorst - http://www.jroller.com/page/dashorstWicket 1.1.1 is out: 
http://wicket.sourceforge.net/wicket-1.1---This SF.net email is sponsored by: Splunk Inc. Do you grep through log filesfor problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user-- Regards, Ali

Re: [Wicket-user] Too many open files problem

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 whatever.
does that sound ok?-IgorOn 2/19/06, Martijn Dashorst
[EMAIL PROTECTED]
wrote:Hmm,The setting could also come from a JNDI lookup, or some other

programmatic way. Perhaps we should take that into account as well.MartijnOn 2/19/06, Igor Vaynberg
[EMAIL PROTECTED] wrote: 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! -Igor On 2/19/06, Gili
[EMAIL PROTECTED] wrote: 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 understand
it is more work than simply removing configure(), but in my view that's like fixing a bug by removing the feature. Just my 2 cents... Gili Andrew Lombardi wrote:
+1 on this.To make the programmatic configure() work just seems like a lot of fluff, don't see why you'd ever need to call this during the app's lifecycle, only at the beginning.
--- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems?Stop!Download the new AJAX search engine that makes
searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user --Living a wicket life...Martijn Dashorst -
http://www.jroller.com/page/dashorst
Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!

http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem



	What is the difference between using configure(DEVELOPMENT) and 
invoking the following code manually in init()?



getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND);
getDebugSettings().setComponentUseCheck(true);
getMarkupSettings().setStripWicketTags(false);
getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_EXCEPTION_PAGE);

	As far as I can see, nothing -- the above code was copied from 
Application.java: configure(configurationType, resourceFinder). That is, 
configure() just sets a whole slew of settings in one shot vs setting 
them individually. Are you saying that if I execute the above code in my 
init() that it will somehow fail? Isn't that a problem in its own right?


Gili

Igor Vaynberg wrote:
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!


-Igor


On 2/19/06, *Gili* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:



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
understand
it is more work than simply removing configure(), but in my view that's
like fixing a bug by removing the feature. Just my 2 cents...

Gili

Andrew Lombardi wrote:
  +1 on this.  To make the programmatic configure() work just seems
like a
  lot of fluff, don't see why you'd ever need to call this during the
  app's lifecycle, only at the beginning.



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




--
http://www.desktopbeautifier.com/


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem



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 whatever.


does that sound ok?

-Igor


On 2/19/06, *Martijn Dashorst* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]  wrote:


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]
mailto:[EMAIL PROTECTED] wrote:
  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!
 
  -Igor
 
 
  On 2/19/06, Gili  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
  
   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
  understand
   it is more work than simply removing configure(), but in my
view that's
   like fixing a bug by removing the feature. Just my 2 cents...
  
   Gili
  
   Andrew Lombardi wrote:
+1 on this.  To make the programmatic configure() work just
seems like a
lot of fluff, don't see why you'd ever need to call this
during the
app's lifecycle, only at the beginning.
  
  
  
   ---
   This SF.net email is sponsored by: Splunk Inc. Do you grep
through log
  files
   for problems?  Stop!  Download the new AJAX search engine that
makes
   searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
  
 
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
 
 


--
Living a wicket life...

Martijn Dashorst - http://www.jroller.com/page/dashorst
http://www.jroller.com/page/dashorst

Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642 
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




--
http://www.desktopbeautifier.com/


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

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 manually in init()?getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND
);getDebugSettings().setComponentUseCheck(true);getMarkupSettings().setStripWicketTags(false);getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_EXCEPTION_PAGE
);As far as I can see, nothing -- the above code was copied fromApplication.java: configure(configurationType, resourceFinder). That is,configure() just sets a whole slew of settings in one shot vs setting
them individually. Are you saying that if I execute the above code in myinit() that it will somehow fail? Isn't that a problem in its own right?GiliIgor Vaynberg wrote: 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! -Igor On 2/19/06, *Gili* 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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 understand it is more work than simply removing configure(), but in my view that's like fixing a bug by removing the feature. Just my 2 cents...
 Gili Andrew Lombardi wrote: +1 on this.To make the programmatic configure() work just seems like a lot of fluff, don't see why you'd ever need to call this during the
 app's lifecycle, only at the beginning. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through
 log files for problems?Stop!Download the new AJAX search engine that makes searching your log files as easy as surfing theweb.DOWNLOAD SPLUNK! 
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net mailto:
Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
--http://www.desktopbeautifier.com/---This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?Stop!Download the new AJAX search engine that makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem

2006-02-19 Thread Martijn Dashorst

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 fetch that value
 from anywhere. by default we can try a sys prop and servlet init
 param/context param whatever.

 does that sound ok?

 -Igor



 On 2/19/06, Martijn Dashorst [EMAIL PROTECTED]  wrote:
 
  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 outside of code so that you can deploy your app and
 not
   have to recompile it just because now you are running in production!
  
   -Igor
  
  
   On 2/19/06, Gili  [EMAIL PROTECTED] wrote:
   
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
   understand
it is more work than simply removing configure(), but in my view
 that's
like fixing a bug by removing the feature. Just my 2 cents...
   
Gili
   
Andrew Lombardi wrote:
 +1 on this.  To make the programmatic configure() work just seems
 like a
 lot of fluff, don't see why you'd ever need to call this during the
 app's lifecycle, only at the beginning.
   
   
   
   
 ---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
   files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD
 SPLUNK!
   
  
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
   
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   
  
  
 
 
  --
  Living a wicket life...
 
  Martijn Dashorst - http://www.jroller.com/page/dashorst
 
  Wicket 1.1.1 is out:
 http://wicket.sourceforge.net/wicket-1.1
 
 
  ---
  This SF.net email is sponsored by: Splunk Inc. Do you grep through log
 files
  for problems?  Stop!  Download the new AJAX search engine that makes
  searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
 
 http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 




--
Living a wicket life...

Martijn Dashorst - http://www.jroller.com/page/dashorst

Wicket 1.1.1 is out: http://wicket.sourceforge.net/wicket-1.1


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] Too many open files problem