IRC Logs

Network: freenode Channel: #tomcat

	Enter your search terms Submit search form
	Web www.irclog.org

[00:27]<drdrvn>+jbalint: http://rentadeveloper.de/blog/
[00:27]<r2rfygv>+cool, thanks
[00:32]<drdrvn>+jbalint: but i still think that the servlet container should do that automaticly.
[00:33]<r2rfygv>+it does via c:url :p
[00:33]<drdrvn>+jbalint: that is not automaticly! that via a special api.
[00:33]<r2rfygv>+I don't think replacing all links and filtering the html is efficient or nice (to the developer).
[00:33]<r2rfygv>+Well presumably c:Url'
[00:33]<drdrvn>+jbalint: it worked for years for php developers.
[00:33]<r2rfygv>+s would be used for links in the same apps and href's would be external links.
[00:34]<r2rfygv>+So a random <a href="...."> in PHP would have a ?sessionid=xxxx appended to it?
[00:34]<drdrvn>+jbalint: php can handle it. it's easy: you just have to thake care of the path.
[00:34]<andxraa>+hey jbalint
[00:34]<r2rfygv>+What do you mean take care of the path?
[00:34]<r2rfygv>+hey keyhack
[00:35]<andxraa>+jbalint, my Spring webapp is getting OutOfHeap errors now, after running for like 10 days or so
[00:35]<r2rfygv>+keyhack: you know where?
[00:35]<andxraa>+jbalint, and realizing that Tomcat/Java seems to be ignoring my -Xms,etc. arguments
[00:35]<andxraa>+jbalint, no, it just throws it for my webapp (but the rest of Tomcat still runs)
[00:35]<r2rfygv>+keyhack: Are you setting it in the right file? I think that is gonvernmet by the launcher.
[00:35]<r2rfygv>+keyhack: you dont have a stack trace or anything?
[00:36]<andxraa>+jbalint, no, the stacktrace is just for the view, which only has a few lines
[00:36]<andxraa>+the JAVA_OPTS environment variable dictates the settings, and I modified catalina.sh to print it out before it launches the JVM and the flags are still there
[00:37]<drdrvn>+jbalint: php just have to thake care of if the url is in the current dir or not...
[00:37]<r2rfygv>+keyhack: have you looked in the jvm section of the server status to see if it shows your values?
[00:38]<r2rfygv>+DaDave: Ok, well .... go PHP then. :) I don't particularly think that is a good idea.
[00:38]<andxraa>+Free memory: 424.77 MB Total memory: 494.50 MB Max memory: 1824.00 MB
[00:38]<r2rfygv>+and max is what you set it to?
[00:39]<andxraa>+I set max to 2048megs
[00:39]<andxraa>+and I set min to 512megs
[00:39]<r2rfygv>+What os?
[00:39]<andxraa>+Solaris 9
[00:39]<andxraa>+i think
[00:39]<andxraa>+or 8, let me check
[00:40]<andxraa>+it's Solaris 9
[00:40]<andxraa>+JVM 1.5.0_07-b03
[00:40]<andxraa>+Tomcat 5.5.12
[00:40]<r2rfygv>+Could be classloader problems. That's where alot of the apps were getting heap errors before.
[00:41]<r2rfygv>+Are you re-deploying the app?
[00:41]<andxraa>+jbalint, thats what I always used to get during re-FTPing during development over and over
[00:41]<andxraa>+QA left the box alone, used it now and then
[00:41]<andxraa>+for days and days, and I checked it this AM, the webapp was fine
[00:41]<andxraa>+and then the QA guy hit it this afternoon, and OutOfHeap
[00:41]<andxraa>+for the whole app, and that was that ;-)
[00:41]<andxraa>+so no, not redeploying
[00:42]<drdrvn>+jbalint: why go php? i have got it woreking with jsp :-)
[00:42]<r2rfygv>+Is it possible there is a leak? have you tried a memory profiler?
[00:43]<r2rfygv>+DaDave: I meant it in the "Go Tigers!!!" sense....
[00:43]<andxraa>+jbalint, its entirely possible
[00:43]<andxraa>+I'm not sure how the beans are used
[00:43]<andxraa>+both the JSF ones and the spring ones
[00:43]<andxraa>+do the JSF beans all get made on a per user/session basis?
[00:44]<andxraa>+and the Spring beans are a per-application basis?
[00:44]<drdrvn>+jbalint: so have you looked at the blog?
[00:44]<r2rfygv>+keyhack: i have no idea about jsf. but the spring stuff should be per-app if you are using the context-loader-listener, and singletons
[00:44]<r2rfygv>+DaDave: yep
[00:45]<drdrvn>+jbalint: what do you think about it?
[00:45]<andxraa>+<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>, yes
[00:45]<andxraa>+singletons? no
[00:45]<r2rfygv>+keyhack: all components are singletons by default
[00:45]<r2rfygv>+so unless you do singleton=false, they are
[00:46]<andxraa>+ah, ok
[00:46]<andxraa>+yeah, I have four spring beans
[00:46]<andxraa>+DAOs
[00:46]<andxraa>+so I was wondering if each user login was creating four new ones
[00:46]<andxraa>+and they werent being released
[00:46]<r2rfygv>+DaDave: looks good. ill add it to yassine's web site if its ok with you.
[00:46]<andxraa>+they are just DAOs, I have much more JSF beans that contain information, etc.
[00:46]<r2rfygv>+keyhack: nope.
[00:47]<andxraa>+hmm
[00:47]<andxraa>+so I'm not sure what could be leaking then
[00:47]<andxraa>+other than beans not being released after the session expires
[00:47]<andxraa>+and the session expiration is set at an hour
[00:47]<r2rfygv>+this is a qa box you said right? so not that many people are using it?
[00:47]<andxraa>+so... im not sure how you could overload the heap with like two people hitting the box within such a small time frame
[00:47]<andxraa>+exactly
[00:48]<andxraa>+i checked it, and i think he hit it maybe an hour or so later
[00:48]<andxraa>+probably after my session even expired
[00:48]<andxraa>+but even then, i've had 3-4 sessions going on at once before on a different machine (although all our machines are very close in specs)
[00:48]<r2rfygv>+well i wouldnt think it is just session, unless you are really leaking. if it were the sessions, i would think it would be with a lot of users, because thats when more sessions are alive
[00:48]<andxraa>+I'm going to have to take the time and try to profile Tomcat
[00:48]<andxraa>+yeah, but we have some shitty designs going on
[00:48]<andxraa>+like the Tree on the left
[00:48]<r2rfygv>+well a memory profiler should show you all you need
[00:49]<andxraa>+is pulled from the DB on every view
[00:49]<r2rfygv>+is it stored on jsf?
[00:49]<andxraa>+because people couldn't finalize a requirements, so its been shipped not caching it
[00:49]<andxraa>+is what stored on JSF?
[00:49]<andxraa>+the JSF just uses the Bean
[00:49]<r2rfygv>+the tree. aren't component models or something stored by jsf?
[00:49]<andxraa>+the Bean is invalidated on every request, basically
[00:49]<r2rfygv>+how?
[00:49]<r2rfygv>+because its requested scoped?
[00:49]<r2rfygv>+or something?
[00:50]<andxraa>+because the JSF page hits the bean, and it re-hits the database and returns the new root node
[00:50]<r2rfygv>+but is it possible that it would hold on to it?
[00:50]<andxraa>+and it just so happens to be request scoped, that one
[00:50]<andxraa>+not really, no
[00:50]<andxraa>+I don't see how
[00:50]<r2rfygv>+ok, then i would imagine it wouldnt
[00:50]<andxraa>+its the same bean

Back to #tomcat
Or go to some related logs:
#gentoo
#gentoo
#netbsd
#gentoo
#gentoo