Re: Shell command to stop and start a webapp without using the manager?
He should be able to use the manager but he'll have to run a copy of it in each Host instance for it to work. On 6/16/05, Marius Scurtescu [EMAIL PROTECTED] wrote: Nikola Milutinovic wrote: [EMAIL PROTECTED] wrote: Hi all, I'd like to know if there's a shell command to stop and start separate web applications. With our configuration, we are unable to use the manager. * We are running Tomcat 5.5 and Apache 2 with the JK Connector (mod_jk) on RedHat Linux. * We have several virtual hosts. When we used 1 service with multiple hosts, we had the problem that our different webapps were sharing the same memory space and they kept stepping on each other. So we split things up. Each host is using a separate service on a different port (see example below). Take a look at Ant Tomcat task. It is used to deploy new webapp from Ant and Ant works from command line. I think this is your best bet. Not to mention that Ant has such a wide variety of other tasks, it is a great boost to your work. You might need to do some other tasks at that time and Ant can help a lot. Of course, if something *is* a job for a shell script, it might be better to do it a s shell script job :-) Ant is also using the manager and Nikola says that they cannot use it for some reason. Nikola, you cannot use the web interface of the manager or you cannot use the manager at all? You can easily write scripts that use wget for example to remotely control Tomcat through the manager (no need to use the web interface in a browser but it has to be accessible). Have a look at: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/manager-howto.html#Supported%20Manager%20Commands Marius - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Virtually, Andre Van Klaveren Architect III, SCP Enterprise Transformation Services Unisys Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrent login detection - how?
I mentioned this issue (killing browser problem) in a previous posting. The only way to prevent this is to invalidate the original session also in the event that a duplicate login was detected. I can see a possible DOS attack problem with this solution though. Maybe you shouldn't invalidate the original session and make the user call helpdesk to invalidate the original session. This would aid in the tracking of this event also. Using IP addresses is usually not a good way to detect duplicate logins. I guess this would work in a controlled environment (intranet) where you can guarantee that the user(s) aren't behind a proxy server. It's definetly not an option for a public site. On 6/15/05, Nikola Milutinovic [EMAIL PROTECTED] wrote: David Rickard wrote: Don't know if this is an optimum solution, but it should work: Keep a List or Vector of IDs for active users in a shared, application-level object (probably ServletContext); When someone logs in, search the List for the submitted ID: if not present, continue with login sequence; if present, kick them to the duplicate login page; Remove IDs from the List when users log out (and add a ServletContextListener to catch people who leave the site without logging out--remove their IDs when their sessions time out); This is definitely a correct approach, but it has onw shortcoming. Suppose one user opens up a session (logs in) and his/her browser dies. The user opens another browser and tries to login, only to be kicked to duplicate user page. I think in this case, the original poster should have a vector or a hash map of user names and remote machine names/IPs. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Virtually, Andre Van Klaveren Architect III, SCP Enterprise Transformation Services Unisys Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrent login detection - how?
This will prevent users from having more than one session at a time for sure. You would probably want to remove the id from the list when a duplicate is detected to prevent users from having to wait for their initial session to timeout in the event that they closed their browser without properly logging out. You would also need to keep the session id in this list so that you can invalidate the session that is related to the id. This of course would drop the original session and in the event that two people were using the same ID it would become a nuisence for the first user to login (they would loose their session). You would want to make sure to log this event for auditing purpose as well. Did I miss anything? -- Virtually, Andre Van Klaveren Architect III, SCP Enterprise Transformation Services Unisys Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] when to share jars
Bottom line is that the only libraries you should put in shared/lib are ones that you know are stable and won't be changing much, if at all (can anybody really know this?). Every application that depends on a shared library gets impacted when you upgrade the shared library. If there are several development teams responsible for applications on the server you now have to coordinate with each team to regression test every impacted application. It's just not worth the time and effort. Like another poster commented, disk is cheap so who cares if your WAR gets bigger. -- Virtually, Andre Van Klaveren Architect III, SCP Enterprise Transformation Services Unisys Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError - 100 thread limit?
We're battling this same problem at our client's site. I think I've identified the same cause (running out of Perm Gen space) but I have to prove it to them first. Hooking a profiler into the Tomcat instance should clearly show this but they don't have one handy. Moving some of the applications to a second instance of Tomcat should also solve this problem. -- Virtually, Andre Van Klaveren Architect III, SCP Enterprise Transformation Services Unisys Corporation On 4/21/05, Caldarale, Charles R [EMAIL PROTECTED] wrote: From: Peter Lin [mailto:[EMAIL PROTECTED] Subject: Re: OutOfMemoryError - 100 thread limit? the default Perm is 64M. If LeeAnn's webapp have a large number of classes, maybe there's too many; therefore forcing the VM to resize the perm. IIRC (haven't looked at core HotSpot code in detail since 1.4.1 days), the virtual address boundary between perm and the other generations is fixed at JVM initialization and never moves. The perm gen does go through GC just like the other gens, but no memory ever moves between the perm and any other space, and the perm gen maximum virtual address range never changes. The HotSpot JVM allocates, but does not commit, all of the -Xmx space at startup in one contiguous block (although there were rumors of that changing in later JVMs). Only the -Xms portion is committed, split up into three regions - young, old, and perm. When a region fills and GC doesn't reduce the usage significantly, additional pages are committed in whichever region needs expanding. I think what was happening is that LeeAnn simply had more classes than would fit in 64 MB. Nothing to do with threads, just the total number of classes in all the applications added together. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat creating new sessions between Servlet-JSP request dispatch under load
Riyad, Close, but it's more like this: 1 client (user) == 1 session. In most cases your client (assuming it's a browser) would only send one request, which would translate into one thread, and therefor you wouldn't have a threading issue with your Session object. There is no guarantee that your users won't either open up multiple browsers and hit your application or, more realistically, they hit the submit button twice therefor generating multiple requests to the server. In this situation it is conceivable that there could be a contention between the two threads and the Session object. This might sound far fetched but I've experienced this problem first hand. In general, you should only place objects in session if you need to access it over several requests and you can't or don't want to retrieve it from persistent storage. If the data is meant for a single request, place your object in request scope and forward to your view component. You mentioned that your problem got worse when you increased the number of requests to the application. This makes sense depending on how you are generating the requests. If you are using a tool that is session aware then you are creating multiple threads that are all trying to use the same Session object. BTW, I copied this reply to the Tomcat Users List because I think this is an important issue that a lot of developers don't understand/realize. I hope that's OK with you. On 4/26/05, Riyad Kalla [EMAIL PROTECTED] wrote: Andre, I appreciate the reply, something you said perked my interesting. You mentioned synchronizing on the session object, but as I understand it: 1 session == 1 thread == 1 client in Tomcat (or most typical application servers). So each client will have their own thread and session object, I don't need to synchronize on it (as I understand) because no two threads will ever be contenting with eachother for access to it. These are the facts that I have learned up until now, but if they are wrong please let me know, this is a pretty big oversight if indeed it is on my part. Best, Riyad On 4/26/05, Andre Van Klaveren [EMAIL PROTECTED] wrote: Riyad, You should not be using the Session object to store your DTO for display. Especially if you are forwarding the request to a JSP. The Session object should only be used to store data that is required to remain in server memory between client requests. I would place your DTO in the Request object instead. That alone will probably solve your problem. Now, assuming you continue to use the Session object, you should synchronize on the Session object before attempting to add your DTO object to it. That will prevent multiple requests from stepping on each other while trying to add their DTOs to the Session. I haven't looked at Tomcat's code to see how they implemented the hashCode method of the Session object but it's not the best way to determine if two Sessions are equal in your case. The hash code may depend on the contents of the Session object. I would print out the session ID instead. This will truely tell you if you have two different sessions. From what you describe I find it hard to beleive that you there is a second session creeping into the picture within the same request. -- Virtually, Andre Van Klaveren SCP -- Virtually, Andre Van Klaveren Architect III, SCP Enterprise Transformation Services Unisys Corporation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat creating new sessions between Servlet-JSP request dispatch under load
Riyad, You should not be using the Session object to store your DTO for display. Especially if you are forwarding the request to a JSP. The Session object should only be used to store data that is required to remain in server memory between client requests. I would place your DTO in the Request object instead. That alone will probably solve your problem. Now, assuming you continue to use the Session object, you should synchronize on the Session object before attempting to add your DTO object to it. That will prevent multiple requests from stepping on each other while trying to add their DTOs to the Session. I haven't looked at Tomcat's code to see how they implemented the hashCode method of the Session object but it's not the best way to determine if two Sessions are equal in your case. The hash code may depend on the contents of the Session object. I would print out the session ID instead. This will truely tell you if you have two different sessions. From what you describe I find it hard to beleive that you there is a second session creeping into the picture within the same request. -- Virtually, Andre Van Klaveren SCP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: filter question
Peter, I don't think Scott wants to modify every JSP in his
application. Sounds like he has a lot!
Scott, the reason your filter isn't working is because the response
from your servlets is getting sent to the client before your filter
has a chance to add it's text to it (using the PrintWriter).
To have this work you need to wrap the original HttpServletResponse
object with your own. You do this by writing your own object that
extends the HttpServletResponse interface. This custom response
object is then passed to the doFilter() method of your filter class.
Your custom HttpServletResponse object needs to also implement it's
own output stream so that you can capture any output that any
downstream code adds to the response. Once the doFilter() method
returns from the stack you can modify the output in your custom
object's output buffer any way you want. Then you just send the
contents of that buffer to the original output stream.
This probably sounds pretty complicated. It's late (for me) and I'm
tired. Sorry. Try doing some research on the
HttpServletResponseWrapper class. It's a convenience class that
already implements the HttpServletResponse interface and implements
the methods of that interface (actually it just delegates the calls to
the underlying response object). All you need to do is extend this
class and override the methods you need to do any custom work. In
your case you'd extend the getOutputStream() method and return your
code's version of the output stream.
To give you an idea of how to do it, do a Google on Servlet filters
(try compression filters). Somebody out there has probably written an
article and/or posted their code. Your code would be similar in
nature.
Good luck!
Virtually,
Andre Van Klaveren
SCP
On Wed, 23 Feb 2005 17:06:06 -0500, Peter Davison [EMAIL PROTECTED] wrote:
Hi Scott.
Your filter should probably set an attribute in the request or perhaps the
session, that your jsp could display, rather than writing to the response's
writer object. By opening up the writer and writing to it you are effectively
setting the response to the request to be the contents of your call to the
printwriter.println() method.
For example: your doFilter method could have something like:
request.setAttribute(IPAddress, getIPAddress());
You'll have to write the getIPAddress() method. :-)
In your jsp, you could pull the stored value out of the request and display it
in the page:
IP Address: %= request.getAttribute(IPAddress) %
Hope that helps...
Regards,
Pete.
Quoting Scott Purcell [EMAIL PROTECTED]:
Hello,
I am having trouble with a filter. Code below.
What I am trying to achieve is as follows: We have a current web-site, with
a
lot of jsp pages, etc. We are moving the code to a load-balanced
environment,
and I would like to put a hidden IP address into each display page. This
way I can know which environment the page came from when debugging, etc.
I figured I could use a 'filter' and have each page insert the IP into
itself
in a hidden field. I am unable to achieve my goal and could use a hand if
anyone has experience with this. Is this possible, or will I have to write
into a header and then edit each jsp page to show the value?
Here is what I have, but it does not print anything on pages.
web.xml
filter
filter-nameHelloWorld/filter-name
filter-classchapter18.HelloWorldFilter/filter-class
/filter
filter-mapping
filter-nameHelloWorld/filter-name
url-pattern/*.jsp/url-pattern
/filter-mapping
And I have the servlet code from SCWCD book
package chapter18;
import java.io.*;
import javax.servlet.*;
public class HelloWorldFilter
implements Filter
{
public void destroy()
{
}
public void doFilter(ServletRequest servletrequest, ServletResponse
servletresponse, FilterChain filterchain)
throws ServletException, IOException
{
PrintWriter printwriter = servletresponse.getWriter();
printwriter.println();
}
public void init(FilterConfig filterconfig)
{
filterConfig = filterconfig;
System.out.println(Chapter 18: HelloWorldFilter initialized);
}
public HelloWorldFilter()
{
}
private FilterConfig filterConfig;
}
Thanks,
Scott
--
Peter Davison _/_/_/ _/_/_/ _/_/_/
e: [EMAIL PROTECTED] _/ _/ _/ _/ _/ _/
w: http://rpdavison.ca _/_/_/ _/_/_/ _/ _/
c: 647 883 6486_/ _/ _/ _/ _/
h: 416 699 2964 _/ _/ _/ _/_/_/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: Allow Apache to Serve Static Content
This assumes of course that you are running Apache and Tomcat on the same server. The concept is pretty much the same though. You set the DocumentRoot to where your static files reside on Apache and map your JSPs and servlets to your JK worker that redirects the request to your Tomcat instance. On Tue, 15 Feb 2005 15:48:18 -0500, Charles N. Harvey III [EMAIL PROTECTED] wrote: Point the DocumentRoot directory to your webapps directory. Then, in your jk mapping, map only *.jsp and *.servlet to Tomcat. ## WEBSITE ## VirtualHost * ServerAdmin [EMAIL PROTECTED] DocumentRoot /code/www/webapps/website/ROOT ServerName www.website.com CustomLog |/code/utils/cronolog/cronolog /logs/apache/website_access_log_%Y_%m_%d.txt combined ErrorLog |/code/utils/cronolog/cronolog /logs/apache/website_error_log_%Y_%m_%d.txt JkMount /*.jsp tomcat JkMount /*.do tomcat /VirtualHost Charlie Dave Morrow said the following on 2/15/2005 3:25 PM: Hi all, I have Apache integrated with Tomcat using mod_jk2 and all is working well with the exception of performance. I would like to direct Apache to serve the static content components of my Java application. How is this done? I presume there must be some type of httpd.conf setting to do this? David A. Morrow Technical Systems Lead Autodata Solutions Company [EMAIL PROTECTED] http://www.autodata.net Tel: (519) 951-6079 Fax: (519) 451-6615 Poor planning on your part does not necessarily constitute an emergency on my part. This message has originated from Autodata Solutions. The attached material is the Confidential and Proprietary Information of Autodata Solutions. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please delete this message and notify the Autodata system administrator at [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to detect expired session vs. no session? (Solved)
The behavior of getSession(false) also depends on whether you're calling it from within a standard Servlet or calling it from the Request passed to a Stuts Action. getSession(false) always returns null if a valid session is not associated with the current request (whether or not the client sent a session ID). Now, in a Stuts Action, it will always return a non-null value because apparently Stuts tries to do the developer a favor and creates a new Session if a valid one doesn't already exist. I haven't determined if this behavior can be altered in Stuts. I haven't looked at the Struts code yet but this was observed on the project I'm working on now. I had to write my own code to make sure that the request had a valid session before taking action. On Sat, 11 Dec 2004 02:34:58 +0800, Joseph Lam [EMAIL PROTECTED] wrote: Steve Kirk wrote: By default: 1. getSession(true)!=null 2. getSession(false)!=null But if a JSP page contains the tag %@ page session=false %, then: 1. getSession(true)!=null 2. getSession(false)==null In the last of these 4 cases, do you mean that the implicit JSP session object returns null, or that request.getSession(false) returns null? I could understand the first behaviour but would be surprised by the second. The problem is that it implies that JSPs execute the code in a way that is different than if it were included in a servlet, and given that JSPs are servlets, this seems puzzling. Again, perhaps I'm not fully understanding either your case, or the details of how sessions work. I'll do some testing to confirm whether the implicit session object is null (which I guess so). I'm sure request.getSession(false) can really be null coz I'm relying on that in my pages, which all are forced not to create session by default until I received the login params and authenticate them, and then manually call HttpSession mySession = request.getSession(true) to create one. For my case, sessions will only be created for logged-in users what is it about your case that makes this happen? I would have thought that session creation is independent of whether you are authenticating or not. Or is there a way to config TC to not create sessions by default, and only create them when the user successfully authenticates? Add this and TC won't create session by default: %@ page session=false % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: %@page isThreadSafe=false % does not work
I have to agree with Yoav. You shouldn't use the isThreadSafe directive unless you absolutely have to (why would you?). I would reconsider your design if you think you need to use this directive. On the other hand, AFAIK, the servlet spec only requires the container to guarantee synchronized access to the servlet when the isThreadSafe directive is set to true. It doesn't specify how it is implemented. The SingleThreadModel has been deprecated so I wouldn't expect any recent Servlet container to implement it. I would guess, as I have never used this directive, that the JSP translator would synchronize the methods on the Servlet. Have you checked the access modifiers on the servlet methods? There are probably several ways a container can achieve synchronized access to the servlet. Regards, Andre Van Klaveren, SCJP http://www.vanklaverens.com On Mon, 6 Dec 2004 23:22:57 +0800, zerol tib [EMAIL PROTECTED] wrote: Howdy, I compared two servlets' source code compiled from JSPs, at the beginning of one jsp I add page directive: [EMAIL PROTECTED] isThreadSafe=false % and the other, [EMAIL PROTECTED] isThreadSafe=true %. But the two servlet are the same , I had thought the first servlet will implement interface SingleThreadModel, but it didn't. Could anyone give me a hint? BTW, jsp compiler (Lomboz) says SingleThreadModel is deprecated. Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
