RE: thread deadlock problem
Hi Antonio,
> Are you absolutely sure of that?
> Could you please triple-check it? A System.out.println("something") at
> the *very* beginning of the doGet/doPost method would be enough.
Yeah. I'm basing it on the timestamps in the log4j log messages (which I've
never yet seen to be wrong). And I've verified it numerous times.
> Strange... Unlikely... but possible...
Yeah, that's what I thought too.
> And you would not make your writer wait, so your process would be
> faster, wouldn't it?
Yes, it would be faster (at least theoretically, although in practice
blocking doesn't occur unless the pipe fills up...so by tuning the size of
your pipe you should be able to come up with something that is just as fast,
in XX% of the cases). The downside of writing the whole thing to memory is
that in this small percentage of scenarios, the entire document gets written
to memory first, and if its a report that is hundreds of pages long, its
possible to run your server out of memory under load.
So the piped approach (if I could get it to work), would be preferable, even
if there's a slight hit on throughput. But if I can't, I can live with the
in-memory version.
Christian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
"Coffee? I could quit anytime, just not today"
> -Original Message-
> From: Antonio Fiol Bonnin [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 21, 2004 3:42 AM
> To: Tomcat Users List
> Subject: Re: thread deadlock problem
>
>
> Christian Cryder wrote:
>
> >This works perfectly about 99% of the time. What we are observing is that
> >there are certain situations where we encounter a deadlock scenario (and
> >that's what prompted my original question). Basically, req2a writes the
> >redirect back to the client, the client receives the redirect
> and actually
> >sends a request back to the server (verified this by using a proxy to
> >examine what is getting sent)... BUT - if req2a is already in
> the blocking
> >code, tomcat simply does not accept req3 until the blocking code
> times out!
> >Bad.
> >
> >
>
> Are you absolutely sure of that?
>
> Could you please triple-check it? A System.out.println("something") at
> the *very* beginning of the doGet/doPost method would be enough.
>
> Without seeing the code, I'd say there is a missing notifyAll() or
> notify() somewhere, to wake up the thread that is wait()'ing.
>
>
> >Now what's interesting is that tomcat itself is not blocked at
> this point -
> >I can send requests from other browsers, and those get handled
> just fine. So
> >something seems to be happening where Tomcat cannot accept this
> particular
> >request (req3), perhaps because its still trying to keep the physical
> >connection associated with req2a open(?) (I'm thinking
> keep-alives here...in
> >other words, if the browser is using keep-alives, req3 will be
> coming across
> >the same physical connection as req2a, so its almost like tomcat
> thinks it
> >still can't receive a new request across this connection, although the
> >browser thinks its fine to go ahead and send it). But after
> req2a writes the
> >redirect response to the browser, I close the writer and flush
> the buffer -
> >there's nothing else I can do to say "hey, I really am done with that
> >response" (even though I'm going to continue running in the background on
> >the server and writing additional data - the real response, the
> report - to
> >a memory structure).
> >
> >
>
> Strange... Unlikely... but possible...
>
>
> >One easy solution is just to modify our piped reader/writer so
> that when the
> >pipe size gets maxed it simply expands the size of the pipe.
> This would mean
> >that we'd never actually have to block, so we'd never hit our
> deadlock. The
> >downside is that it now means that in some cases we might be
> significantly
> >increasing the size of our memory footprint for the server.
> Another option,
> >I suppose, would be to simply pipe the document to disk, rather
> than storing
> >it to memory.
> >
> >
>
> And you would not make your writer wait, so your process would be
> faster, wouldn't it?
>
>
> HTH,
>
>
> Antonio Fiol
>
> -
> 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: Session not destroyed after server shutdown
Hi Jake! But this means everything you put in the session needs to be serializable, right? I don't think this impacts Barracuda (because I don't think its saving anything in the session - just creating the OR wrappers over the session), but we might want to check. Of course, we can continue that conversation on the bmvc list... Christian -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- "Coffee? I could quit anytime, just not today" > -Original Message- > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 10:20 AM > To: Tomcat Users List > Subject: Re: Session not destroyed after server shutdown > > > Sessions aren't destroyed until the session times out. If you > shut the server > down, existing sessions will be written to file. If you bring > the server back > up before the timeout of those sessions, they will still exist upon server > restart. If you think about it, this is usually desired > behavior. I believe > you can turn this off on the Coyote connector, but I've forgotten > how. I can't > imagine why you wouldn't want it to work this way. What if you were doing > emergency server maintainance and had to restart the app while > some users were > connected. Blowing away their sessions would normally be > undesired. You can > always delete the work directory for the app if you actually do > desire to blow > away sessions as well. > > Jake > > Quoting Joao Batistella <[EMAIL PROTECTED]>: > > > Hello! > > > > I'm using Tomcat 4 and all sessions that I have when the server > is up are > > not > > destroyed when I shutdown te server. I've implemented a > > ServletContextListener > > to register when the app is going down and a > HttpSessionListener to see when > > a session is destroyed. When the server goes down the sessions are not > > destroyed and, when it comes up again, the sessions are still > there. If I > > try to get a session attribute by some key before setting the > same attribute > > I have a result different of null. > > Anyone knows what is this? > > > > My sofwate versions: > > Windows XP Professional > > Tomcat 4.1.29-LE > > J2sdk 1.4.2 > > > > Thanks, > > JP > > - > 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: thread deadlock problem
Hi Hans,
> is performed repeatedly in a while lus?
Yep. It's basically the same as Sun's PipedReader/PipedWriter, but modified
to support the notion of a configurable pipe size and a timeout. I am
attaching the actual classes so you can see them (cf. line 218 in
BetterPipedReader)
> What's the notifyAll doing there by the way?
Well, its in there because the Sun code had it in there. My understanding of
what's going on is that if the writer blocks it does a notifyAll to wake up
any pending readers, and the readers do something similar when they read (to
wake up any pending writers that may be blocked because the pipe was full).
My understanding of their use of wait is a little shakier - I thought that
substituting sleep(xxx) instead would basically do the same thing, but it
doesn't - the whole thing craps out then. So I left it as wait()
> And is this code being executed in a synchronized block?
Yep. Its happening in
protected synchronized void receive(int c)
But the writer thread (req2a) is the only thread calling this method. The
reader thread (req3 - when it gets there) will be calling
public synchronized int read()
Its interesting to me that the way Sun has implemented this, they don't
actually have to synchronize access to the underlying data structure (a
char[]) - they just have 2 indexes: one for read position and one for write
position. I thought was kind of clever. But they are still synching on the
methods, so I'm not sure whether they're actually gaining much in
performance or not.
Christian
------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
"Coffee? I could quit anytime, just not today"
> -Original Message-
> From: Hans [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 19, 2004 9:33 AM
> To: Tomcat Users List
> Subject: RE: thread deadlock problem
>
>
> ok,
> and can you give some more details on the blocking code.
> I assume :
> ...check to see if data pipe still full
> > > ...timeout if we've waited too long
> > >
> > > notifyAll();
> > > try {
> > > wait(1000);
> > > Thread.yield();
> > > } catch (InterruptedException ex) {
> > > throw new java.io.InterruptedIOException();
> > > }
>
> is performed repeatedly in a while lus?
> What's the notifyAll doing there by the way?
> And is this code being executed in a synchronized block?
>
> grtz
> Hans
>
> At 09:01 19/03/2004 -0500, you wrote:
> > > is the thread mentioned in 2b the same as the one that handled 2a ?
> >
> >Yep, same thread.
> >
> >--
> >Christian Cryder
> >Internet Architect, ATMReports.com
> >Project Chair, BarracudaMVC - http://barracudamvc.org
> >--
> >"Coffee? I could quit anytime, just not today"
> >
> >
> > > -Original Message-
> > > From: Hans [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, March 19, 2004 8:21 AM
> > > To: Tomcat Users List
> > > Subject: Re: thread deadlock problem
> > >
> > >
> > > hi,
> > > is the thread mentioned in 2b the same as the one that handled 2a ?
> > >
> > > grtz
> > > Hans
> > >
> > > At 07:55 19/03/2004 -0500, you wrote:
> > > >Hi folks,
> > > >
> > > >I need to know if someone can explain the following behavior:
> > > >
> > > >1. client browser issues a request
> > > >2. tomcat servlet code starts handling the request...
> > > > a. writes an html redirect to the resp, flushes the buffer, etc
> > > > b. thread continues processing (writing to a data structure)
> > > >3. client browser receives 2a response and generates another
> request...
> > > > a. reads data out of the data structure populated by 2b
> > > >
> > > >What's happening is that 2b fills up the structure and then
> > > blocks, waiting
> > > >until 3a reads some of the data out, so that it can continue.
> > > The blocking
> > > >code looks like this:
> > > >
> > > > ...check to see if data pipe still full
> > > > ...timeout if we've waited too long
> > > >
> > > > notifyAll();
> > > > try {
> > > > wait(1000);
> > > > Thread.yield();
> > > > } catch
RE: thread deadlock problem
> is the thread mentioned in 2b the same as the one that handled 2a ?
Yep, same thread.
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
"Coffee? I could quit anytime, just not today"
> -Original Message-
> From: Hans [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 19, 2004 8:21 AM
> To: Tomcat Users List
> Subject: Re: thread deadlock problem
>
>
> hi,
> is the thread mentioned in 2b the same as the one that handled 2a ?
>
> grtz
> Hans
>
> At 07:55 19/03/2004 -0500, you wrote:
> >Hi folks,
> >
> >I need to know if someone can explain the following behavior:
> >
> >1. client browser issues a request
> >2. tomcat servlet code starts handling the request...
> > a. writes an html redirect to the resp, flushes the buffer, etc
> > b. thread continues processing (writing to a data structure)
> >3. client browser receives 2a response and generates another request...
> > a. reads data out of the data structure populated by 2b
> >
> >What's happening is that 2b fills up the structure and then
> blocks, waiting
> >until 3a reads some of the data out, so that it can continue.
> The blocking
> >code looks like this:
> >
> > ...check to see if data pipe still full
> > ...timeout if we've waited too long
> >
> > notifyAll();
> > try {
> > wait(1000);
> > Thread.yield();
> > } catch (InterruptedException ex) {
> > throw new java.io.InterruptedIOException();
> > }
> >
> >Now what is happening is that in certain situations, the request for 3a
> >never gets accepted by the server until 2b times out. I'm trying to
> >understand why (and what to do about it). I have verified that the client
> >not only receives the response from 2a, but it actually issues
> the request
> >for 3a. Nevertheless, once Tomcat is in this blocking code
> (above) it does
> >not seem to accept requests from this particular browser window,
> -UNTIL- 2b
> >times out.
> >
> >Can anyone explain this to me? Should I be blocking/yielding in
> some other
> >fashion? Why won't Tomcat accept my subsequent requests when I'm in this
> >blocking code?
> >
> >What I'm looking for more than just "that's a stupid thing to do" - I'm
> >hoping someone can either
> >
> >a) explain the nitty-gritty of how tomcat handles writing the
> code back to
> >the browser (and telling the browser that everything is complete) in the
> >case where the thread may actually need to continue running for a longer
> >period of time -or-
> >
> >b) offer some constructive suggestions as to where I should
> start looking in
> >the tomcat code to answer those questions myself
> >
> >Any suggestions would be greatly appreciated...
> >
> >tia,
> >Christian
> >--
> >Christian Cryder
> >Internet Architect, ATMReports.com
> >Project Chair, BarracudaMVC - http://barracudamvc.org
> >--
> >"Coffee? I could quit anytime, just not today"
> >
> >
> >-
> >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]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: thread deadlock problem
ed reader/writer so that when the
pipe size gets maxed it simply expands the size of the pipe. This would mean
that we'd never actually have to block, so we'd never hit our deadlock. The
downside is that it now means that in some cases we might be significantly
increasing the size of our memory footprint for the server. Another option,
I suppose, would be to simply pipe the document to disk, rather than storing
it to memory.
I can (and will) look at both of these if need be, but first I'd prefer to
hear if there is something obvious that exlains the behavior of tomcat - I'd
really like to understand why what we're doing only deadlocks in a very
small percentage of our cases. I'd like to understand why our blocking code
does not allow tomcat to continue (as I'd expect), and why tomcat can't turn
around and accept req3 from the browser in this situation.
Long answer to a short question, but hopefully that helps flesh things out.
THanks much,
CHristian
--
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
"Coffee? I could quit anytime, just not today"
> -Original Message-
> From: Edson Alves Pereira [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 19, 2004 8:00 AM
> To: 'Tomcat Users List'
> Subject: RE: thread deadlock problem
>
>
> Why are you trying to do this kind of control?
>
> > --
> > De: Christian Cryder[SMTP:[EMAIL PROTECTED]
> > Responder: Tomcat Users List
> > Enviada:sexta-feira, 19 de março de 2004 9:55
> > Para: Tomcat-User
> > Assunto:thread deadlock problem
> >
> > Hi folks,
> >
> > I need to know if someone can explain the following behavior:
> >
> > 1. client browser issues a request
> > 2. tomcat servlet code starts handling the request...
> > a. writes an html redirect to the resp, flushes the buffer, etc
> > b. thread continues processing (writing to a data structure)
> > 3. client browser receives 2a response and generates another request...
> > a. reads data out of the data structure populated by 2b
> >
> > What's happening is that 2b fills up the structure and then blocks,
> > waiting
> > until 3a reads some of the data out, so that it can continue.
> The blocking
> > code looks like this:
> >
> > ...check to see if data pipe still full
> > ...timeout if we've waited too long
> >
> > notifyAll();
> > try {
> > wait(1000);
> > Thread.yield();
> > } catch (InterruptedException ex) {
> > throw new java.io.InterruptedIOException();
> > }
> >
> > Now what is happening is that in certain situations, the request for 3a
> > never gets accepted by the server until 2b times out. I'm trying to
> > understand why (and what to do about it). I have verified that
> the client
> > not only receives the response from 2a, but it actually issues
> the request
> > for 3a. Nevertheless, once Tomcat is in this blocking code
> (above) it does
> > not seem to accept requests from this particular browser window, -UNTIL-
> > 2b
> > times out.
> >
> > Can anyone explain this to me? Should I be blocking/yielding in
> some other
> > fashion? Why won't Tomcat accept my subsequent requests when I'm in this
> > blocking code?
> >
> > What I'm looking for more than just "that's a stupid thing to do" - I'm
> > hoping someone can either
> >
> > a) explain the nitty-gritty of how tomcat handles writing the
> code back to
> > the browser (and telling the browser that everything is complete) in the
> > case where the thread may actually need to continue running for a longer
> > period of time -or-
> >
> > b) offer some constructive suggestions as to where I should
> start looking
> > in
> > the tomcat code to answer those questions myself
> >
> > Any suggestions would be greatly appreciated...
> >
> > tia,
> > Christian
> > --
> > Christian Cryder
> > Internet Architect, ATMReports.com
> > Project Chair, BarracudaMVC - http://barracudamvc.org
> > --
> > "Coffee? I could quit anytime, just not today"
> >
> >
> > -
> > 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]
thread deadlock problem
Hi folks,
I need to know if someone can explain the following behavior:
1. client browser issues a request
2. tomcat servlet code starts handling the request...
a. writes an html redirect to the resp, flushes the buffer, etc
b. thread continues processing (writing to a data structure)
3. client browser receives 2a response and generates another request...
a. reads data out of the data structure populated by 2b
What's happening is that 2b fills up the structure and then blocks, waiting
until 3a reads some of the data out, so that it can continue. The blocking
code looks like this:
...check to see if data pipe still full
...timeout if we've waited too long
notifyAll();
try {
wait(1000);
Thread.yield();
} catch (InterruptedException ex) {
throw new java.io.InterruptedIOException();
}
Now what is happening is that in certain situations, the request for 3a
never gets accepted by the server until 2b times out. I'm trying to
understand why (and what to do about it). I have verified that the client
not only receives the response from 2a, but it actually issues the request
for 3a. Nevertheless, once Tomcat is in this blocking code (above) it does
not seem to accept requests from this particular browser window, -UNTIL- 2b
times out.
Can anyone explain this to me? Should I be blocking/yielding in some other
fashion? Why won't Tomcat accept my subsequent requests when I'm in this
blocking code?
What I'm looking for more than just "that's a stupid thing to do" - I'm
hoping someone can either
a) explain the nitty-gritty of how tomcat handles writing the code back to
the browser (and telling the browser that everything is complete) in the
case where the thread may actually need to continue running for a longer
period of time -or-
b) offer some constructive suggestions as to where I should start looking in
the tomcat code to answer those questions myself
Any suggestions would be greatly appreciated...
tia,
Christian
------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
--
"Coffee? I could quit anytime, just not today"
-
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: Configuring Tomcat connections
Ok, so I tried upgrading to Tomcat 5.0.16, and I am still seeing similar results (slightly better). I am hitting the standard HelloWorld servlet (http://localhost:8080/servlets-examples/servlet/HelloWorldExample). When I get over about 16-17 simultaneous connections, I start getting connect expections. I am using the default server configuration from server.xml (and once again, changing these values does not seem to make any difference whatsoever): So how come I can't get more than 20 connections at a time? What gives??? Christian (I am running on Win2K Pro, by the way; latest service packs, 512 MB Ram) -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- "Coffee? I could quit anytime, just not today" > -Original Message- > From: Christian Cryder [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 15, 2004 2:32 PM > To: Tomcat-User > Subject: Configuring Tomcat connections > > > Can someone offer some suggestions on configuring the number of > connections > Tomcat 4.1 will accept? I am using a stress tester to access the sample > servlet (http://localhost:8080/examples/servlet/HelloWorldExample). > Somewhere around 14-15 concurrent requests, I start seeing > "java.net.ConnectException: Connection refused: connect" > > Looking in the Tomcat server.xml file, I see > > port="8080" minProcessors="5" maxProcessors="75" >enableLookups="true" redirectPort="8443" >acceptCount="10" debug="0" connectionTimeout="2" >useURIValidationHack="false" /> > > I assume this is the connector I'm going through (since my URL is > referring > to port 8080). According to the docs > (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/webapp.html) > acceptCount and maxProcessors should affect this behavior, but I am not > seeing any changes when I adjust them upwards. Should I be looking > elsewhere? Anyone have any suggestions? > > Thanks, > Christian > -- > Christian Cryder > Internet Architect, ATMReports.com > Project Chair, BarracudaMVC - http://barracudamvc.org > -- > "Coffee? I could quit anytime, just not today" > > > - > 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]
Configuring Tomcat connections
Can someone offer some suggestions on configuring the number of connections Tomcat 4.1 will accept? I am using a stress tester to access the sample servlet (http://localhost:8080/examples/servlet/HelloWorldExample). Somewhere around 14-15 concurrent requests, I start seeing "java.net.ConnectException: Connection refused: connect" Looking in the Tomcat server.xml file, I see I assume this is the connector I'm going through (since my URL is referring to port 8080). According to the docs (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/webapp.html) acceptCount and maxProcessors should affect this behavior, but I am not seeing any changes when I adjust them upwards. Should I be looking elsewhere? Anyone have any suggestions? Thanks, Christian -- Christian Cryder Internet Architect, ATMReports.com Project Chair, BarracudaMVC - http://barracudamvc.org -- "Coffee? I could quit anytime, just not today" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 4.1 ignoring -Xmx params
> As an aside, and this applies for windows as well as linux/solaris: -Xms > and -Xmx control the size of the JVM heap. That's not the total JVM > size. There are other spaces, e.g. the stack, symbol tables, and OS > process overhead, that contribute to the overall process size. > > How much they contribute depends on the OS version, JDK version, and > other things, and is very difficult to predict precisely. You can > measure it at any given point by comparing the output from an OS-level > top (e.g. top on linux, or the task manager in windows) to the output of > Runtime.getRuntime().totalMemory(). You will always see a difference. Excellent point, and one I had considered. > So if you're basing your assertion that -Xmx is ignored on the output of > an OS-level tool, please rethink your assertion in light of the above. Ok, so this _is_ what I'm basing it on (looking at MS's Task manager). BUT...it still doesn't seem reasonable that the actual memory used is 150 MB > than the limit specified to the JVM. In other words, if I tell the JVM "-Xmx512" and the OS Task Mgr is reporting that Tomcat is using 670 MB, doesn't this seem like more than just an overhead issue? I'm perfectly content if that is in fact the answer, I'm just trying to confirm whether or not we have a problem. Any suggestions? tia, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- "Coffee? I could quit anytime, just not today" > -Original Message- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 28, 2003 10:21 AM > To: Tomcat Users List > Subject: RE: Tomcat 4.1 ignoring -Xmx params > > > Howdy, > As an aside, and this applies for windows as well as linux/solaris: -Xms > and -Xmx control the size of the JVM heap. That's not the total JVM > size. There are other spaces, e.g. the stack, symbol tables, and OS > process overhead, that contribute to the overall process size. > > How much they contribute depends on the OS version, JDK version, and > other things, and is very difficult to predict precisely. You can > measure it at any given point by comparing the output from an OS-level > top (e.g. top on linux, or the task manager in windows) to the output of > Runtime.getRuntime().totalMemory(). You will always see a difference. > > So if you're basing your assertion that -Xmx is ignored on the output of > an OS-level tool, please rethink your assertion in light of the above. > If you're basing it on the actual Runtime.totalMemory() output, then you > are correct in saying you likely did not install tomcat correctly. > > Yoav Shapira > Millennium ChemInformatics > > > >-Original Message- > >From: Christian Cryder [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, January 28, 2003 12:10 PM > >To: Tomcat Users List > >Subject: RE: Tomcat 4.1 ignoring -Xmx params > > > >What we are doing is running Tomcat as a service on a production > server; we > >specify both -Xmx and -Xms values. What we are seeing is that after > several > >days of use, Tomcat is well over the max, by a magnitude of 100+ MB. > Our > >experience has been that when we run it manually it seems to stay > within > >the > >bounds, but when running as a service it seems to go beyond them. So > >perhaps > >we're not installing the service correctly... > > > >Christian > >-- > >Christian Cryder [[EMAIL PROTECTED]] > >Internet Architect, ATMReports.com > >Barracuda - http://barracudamvc.org > >-- > >"Coffee? I could quit anytime, just not today" > > > >> -Original Message- > >> From: Hari Venkatesan [mailto:[EMAIL PROTECTED]] > >> Sent: Tuesday, January 28, 2003 10:02 AM > >> To: Tomcat Users List > >> Subject: RE: Tomcat 4.1 ignoring -Xmx params > >> > >> > >> How did you find out it is ignoring -Xmx parameter. Initially when > you > >> start up tomcat, it would allocate only the minimum heap that you set > in > >> -Xms. > >> > >> Hari > >> > >> > >> > >> >-Original Message- > >> >From: Christian Cryder [mailto:[EMAIL PROTECTED]] > >> >Sent: Tuesday, January 28, 2003 11:49 AM > >> >To: Tomcat-User > >> >Subject: Tomcat 4.1 ignoring -Xmx params > >> > > >> >Hey folks, has anyone observed s
RE: Tomcat 4.1 ignoring -Xmx params
What we are doing is running Tomcat as a service on a production server; we specify both -Xmx and -Xms values. What we are seeing is that after several days of use, Tomcat is well over the max, by a magnitude of 100+ MB. Our experience has been that when we run it manually it seems to stay within the bounds, but when running as a service it seems to go beyond them. So perhaps we're not installing the service correctly... Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- "Coffee? I could quit anytime, just not today" > -Original Message- > From: Hari Venkatesan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 28, 2003 10:02 AM > To: Tomcat Users List > Subject: RE: Tomcat 4.1 ignoring -Xmx params > > > How did you find out it is ignoring -Xmx parameter. Initially when you > start up tomcat, it would allocate only the minimum heap that you set in > -Xms. > > Hari > > > > >-Original Message- > >From: Christian Cryder [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, January 28, 2003 11:49 AM > >To: Tomcat-User > >Subject: Tomcat 4.1 ignoring -Xmx params > > > >Hey folks, has anyone observed scenarios where Tomcat appears to ignore > >the -Xmx param? We are running 4.1 as a service on Win 2000 Pro, and > have > >manually uninstalled/reinstalled the tomcat service as follows: > > > >to uninstall: > >- > >tomcat.exe -uninstall "Apache Tomcat 4.1" > > > >to install: > >- > >tomcat -install "Apache Tomcat 4.1" > >"E:\sun\j2sdk1.4.1_01\jre\bin\client\jvm.dll" -Xmx256m -Xms128m - > >Djava.class > >.path="D:\Program Files\Apache Group\Tomcat > >4.1\bin\bootstrap.jar" -Dcatalina.home="D:\Program Files\Apache > >Group\Tomcat > >4.1" -Djava.endorsed.dirs="D:\Program Files\Apache Group\Tomcat > >4.1\common\endorsed" -start > >org.apache.catalina.startup.BootstrapService -params start -stop > >org.apache.catalina.startup.BootstrapService -params stop -out > "D:\Program > >Files\Apache Group\Tomcat 4.1\logs\stdout.log" -err "D:\Program > >Files\Apache > >Group\Tomcat 4.1\logs\stderr.log" > > > >What we are seeing here is that everything seems to work just fine, but > >Tomcat does not seem to stop at the 256m max that we are requesting? Is > >this > >to be expected? Or are we doing something stupid? > > > >Thanks much, > >Christian > >-- > >Christian Cryder [[EMAIL PROTECTED]] > >Internet Architect, ATMReports.com > >Barracuda - http://barracudamvc.org > >-- > >"Coffee? I could quit anytime, just not today" > > > > > >-- > >To unsubscribe, e-mail: <mailto:tomcat-user- > >[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:tomcat-user- > >[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Tomcat 4.1 ignoring -Xmx params
Hey folks, has anyone observed scenarios where Tomcat appears to ignore the -Xmx param? We are running 4.1 as a service on Win 2000 Pro, and have manually uninstalled/reinstalled the tomcat service as follows: to uninstall: - tomcat.exe -uninstall "Apache Tomcat 4.1" to install: - tomcat -install "Apache Tomcat 4.1" "E:\sun\j2sdk1.4.1_01\jre\bin\client\jvm.dll" -Xmx256m -Xms128m -Djava.class .path="D:\Program Files\Apache Group\Tomcat 4.1\bin\bootstrap.jar" -Dcatalina.home="D:\Program Files\Apache Group\Tomcat 4.1" -Djava.endorsed.dirs="D:\Program Files\Apache Group\Tomcat 4.1\common\endorsed" -start org.apache.catalina.startup.BootstrapService -params start -stop org.apache.catalina.startup.BootstrapService -params stop -out "D:\Program Files\Apache Group\Tomcat 4.1\logs\stdout.log" -err "D:\Program Files\Apache Group\Tomcat 4.1\logs\stderr.log" What we are seeing here is that everything seems to work just fine, but Tomcat does not seem to stop at the 256m max that we are requesting? Is this to be expected? Or are we doing something stupid? Thanks much, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracudamvc.org -- "Coffee? I could quit anytime, just not today" -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
security-constraint problems
Hi folks! I'm observing a couple of problems with security-constraints, and I'd like to know wether I'm encountering bugs in Tomcat or simply doing something stupid. Here are the details: I have a constraint that is setup like this: Test /servlet/HelloWorld *.event User 1. URL patterns with wildcards do not seem to be matching. For instance, given a url of http://localhost:8080/MyApp/GoHome.event, when I use the following url patterns, I do not get challenged: /*.event *.event If I use the specific url, however: /GoHome.event then it does in fact work and I get prompted for user/pwd as expected. So my question is, am I doing somethign wrong or is this in fact a bug? 2. When I try and access Tomcat directly on port 8080 using http://localhost:8080/MyApp/servlet/HelloWorld, I get challenged as expected. When I try to access the exact same URL through IIS using http://localhost/MyApp/servlet/HelloWorld, I don't get challenged at all; I just immediately get an access denied error message. If I remove the url pattern for /servlet/HelloWorld, then I can access it just fine through IIS, which tells me that the isapi redirection is working ok. Again, am I doing something wrong, or is this a bug? Should role based authentication work when integrating Tomcat with IIS? Thanks, Christian ---------- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- "What a great time to be a(n employed) Geek" -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
JNDI Q's
Ok, I've searched through most of the docs now and I have some very basic JDNI specific questions: 1. Are there any parts of JNDI which are _not_ included with Tomcat 4.0.1? (ie. is there anything that still needs to be downloaded/installed separately?) 2. What exactly is the relationship between what gets defined in server.xml and a specific webapp's web.xml? In other words, I see how you define a JNDI resource in server.xml using and -- as I understand it this makes a resource available to a particual context (ie. webapp). What then, is the purpose of also defining the resource using in that app's web.xml file? 3. Is there any way to define a JNDI resource just through the web.xml file (as opposed to using server.xml file?) When you change web.xml, you can only need to cycle the webapp; when you change server.xml you have to cycle the entire server, which I'd like to avoid. 4. Is there anyway to use the Tomcat manager app to cycle the whole server? What's the best way to do this? (especially if Tomcat is running as an NT service!) Thanks, Christian ------ Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- "What a great time to be a(n employed) Geek" -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
JNDI problems
Hi folks,
Ok, I'm using Tomcat 4.0.1, and am trying to access a JDBC datasource via
JNDI. I've tried to study the docs before asking stupid questions, but I'm
completely stuck right now and am hoping someone can see what I'm doing
wrong.
The primary resources that I've been using include:
1. http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
2. http://www.j-netdirect.com/JSQLTechRef.htm#J2EE_DataSource
Based on the instructions, my server.xml defines a resource like this:
databasepubs
driverClassNamecom.jnetdirect.jsql.JSQLDataSource
driverNamejdbc:JSQLConnect:
usersa
password
My Test99 webapp's web.xml in turn defines a resource like this:
Sample JDBC Resource
jdbc/Test99DB
javax.sql.DataSource
Container
And finally, my servlet code looks like this:
initCtx = new InitialContext();
envCtx = (Context) initCtx.lookup("java:comp/env");
ds = (DataSource) envCtx.lookup("jdbc/Test99DB");
When I run this, initCtx and envCtx both seem to get loaded properly
(they're not null). When I try to lookup the DataSource, however, it always
comes back as null. When I add some debugging stmts, like this:
System.out.println("initCtx:"+initCtx);
System.out.println("envCtx:"+envCtx);
NamingEnumeration enum = envCtx.list("jdbc/");
while (enum.hasMore()) {System.out.println(" --> "+enum.next());}
System.out.println("ds:"+ds);
here's the output I get:
initCtx:javax.naming.InitialContext@5ddb6e
envCtx:org.apache.naming.NamingContext@71235b
--> Test99DB: org.apache.naming.ResourceRef
ds:null
So it looks like JNDI is working and the resource is available; why then is
ds coming back as null? Am I doing something stupid? I'm really confused on
this one; if you have any suggestions I'd love to hear from you.
tia,
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
"What a great time to be a(n employed) Geek"
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
RE: Tomcat 4 & Runtime.exec()? (solved)
Hi guys,
Well, I just figured it out...turns out that when I run it as a standalone
application, something like this works just fine:
File path = new File("C:/temp99");
String cmd = "test.bat";
Runtime.getRuntime().exec(cmd, null, path);
When I run it in Tomcat, however, the cmd _must_ include the path, like
this:
File path = new File("C:/temp99");
String cmd = "C:/temp99/test.bat";
Runtime.getRuntime().exec(cmd, null, path);
If I don't do this, it blows up. Is that wierd or what? What I can't figure
out is that in both cases I am using the same JDK (1.3.1), so I'm not sure
why the first example works standalone but not in a servlet. Wierd wierd
wierd. Oh well, at least it works... *sigh* :-)
Thanks for your everyone's help!
Christian
------
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
"What a great time to be a(n employed) Geek"
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> he.org]On Behalf Of Christian Cryder
> Sent: Friday, January 25, 2002 7:43 PM
> To: Tomcat-User
> Subject: Tomcat 4 & Runtime.exec()?
>
>
> Can anyone tell me why the Runtime.exec() call in the following piece of
> code runs fine standalone, but blows chunks in Tomcat 4?
>
> File path = new File("E:/WebProjects/lutris/cvs/Barracuda/src");
> String[] args = new String[] {"ant.bat","admin.sample1"};
> try {
> Process p = Runtime.getRuntime().exec(args, null, path);
> StringBuffer sbOut = new StringBuffer(1000);
> BufferedReader br = new BufferedReader(new
> InputStreamReader(p.getInputStream()));
> while (true) {
> String s = br.readLine();
> if (s==null) break;
> System.out.println(s);
> }
> br.close();
> p.waitFor();
> System.out.println (sbOut.toString());
> System.out.println ("Exit status: "+p.exitValue());
> } catch (Exception e) {
> System.out.println ("Unexpected error executing cmd:"+e);
> }
>
> Like I said, it works fine when run as an application. But in
> Tomcat, I get
> the following stack trace:
>
> Path: E:\WebProjects\lutris\cvs\Barracuda\src (exists=true)
> Args[0]: ant.bat
> Args[1]: admin.sample1
> Unexpected error executing cmd:java.io.IOException: CreateProcess: ant.bat
> admin.sample1 error=2
> java.io.IOException: CreateProcess: ant.bat admin.sample1 error=2
> at java.lang.Win32Process.create(Native Method)
> at java.lang.Win32Process.(Unknown Source)
> at java.lang.Runtime.execInternal(Native Method)
> at java.lang.Runtime.exec(Unknown Source)
> ...
>
> ...
>
> Suggestions? Is there something I don't know about invoking Runtime.exec()
> from with a servlet?
>
> Thanks,
> Christian
> --
> Christian Cryder [[EMAIL PROTECTED]]
> Internet Architect, ATMReports.com
> Barracuda - http://barracuda.enhydra.org
> --
> "What a great time to be a(n employed) Geek"
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
RE: Accessing Manager app through URLConnection
I was able to get it to work by following the instructions in Craigs email.
I'm attaching a couple of classes that I created to make the whole thing
easy. Basically, look at the very bottom of HttpRequester.java, and you'll
see an example that looks something like this:
HttpRequester hr = new HttpRequester();
String urlStr = "http://localhost:8080/manager/list";;
hr.setRequest(urlStr, HttpRequester.GET, null, "admin", "123123", null);
hr.connect();
String inputLine;
while ((inputLine = hr.readLine()) != null) {
System.out.println(inputLine);
}
hr.disconnect();
urlStr = "http://localhost:8080/manager/reload?path=/examples";;
hr.setRequest(urlStr, HttpRequester.GET, null, "admin", "123123", null);
hr.connect();
String inputLine;
while ((inputLine = hr.readLine()) != null) {
System.out.println(inputLine);
}
hr.disconnect();
Both of these work for me.
Christian
--
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
"What a great time to be a(n employed) Geek"
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> he.org]On Behalf Of Donald Lee
> Sent: Saturday, January 26, 2002 12:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Accessing Manager app through URLConnection
>
>
> I setup mine and it authenticates then gives me,
>
> "FAIL - Unknown command "
>
> I don't even know where to begin troubleshooting because I don't
> know what I
> am supposed to be looking for.
> Localhost_log file has the following,
>
> 2002-01-26 15:13:35 StandardWrapper[/manager:Manager]: Loading container
> servlet Manager
> 2002-01-26 15:13:35 Manager: init
> 2002-01-26 15:13:35 Manager: init: Associated with Deployer 'localhost'
>
> localhost_access_log has
> 192.168.0.1 - - [26/Jan/2002:15:13:33 -0500] "GET /manager
> HTTP/1.1" 401 618
> 192.168.0.1 - dwlee1 [26/Jan/2002:15:13:35 -0500] "GET /manager HTTP/1.1"
> 200 40
>
>
>
> Original Message Follows
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Accessing Manager app through URLConnection
> Date: Sat, 26 Jan 2002 08:46:45 -0800 (PST)
>
>
>
> On Fri, 25 Jan 2002, Christian Cryder wrote:
>
> > Date: Fri, 25 Jan 2002 23:31:28 -0700
> > From: Christian Cryder <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat-User <[EMAIL PROTECTED]>
> > Subject: Accessing Manager app through URLConnection
> >
> > Ok, how can I go about accessing the Manager app through a URL
> connection?
> > Its currently generating a 401 error code, and I know the reason is
> because
> > of the role stuff...how can I programatically assign a role?
> Or is there
> a
> > way I can pass the user/pwd info along with the url
> poarameters somehow?
> I'd
> > greatly appreciate some ideas on this...
> >
>
> Hi Christian,
>
> You are indeed getting a 401 error because the manager webapp is protected
> by a security constraint using BASIC authentication. If you run it from a
> browser, you get the usual pop-up dialog.
>
> To use automated connections, your client code is going to have to create
> an "Authorization" header that encodes the username and password, in the
> format required by RFC 2617, and include it with the request to bypass the
> 401 dialog. One source of code you could use to figure out what's
> necessary is in the HEAD branch of the Tomcat 4 repository -- in class
> org.apache.catalina.ant.AbstractCatalinaTask. (As the name implies, this
> is the base class for a set of custom Ant tasks that interact with the
> Manager webpp, documented on the "manager-howto.html" page in the nightly
> builds of Tomcat 4.
>
> > THanks,
> > Christian
> >
>
> Craig McClanahan
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
>
>
>
>
> --
> I am Microsoft of Borg. You will be assimilated.
> Resistance is futi . . .
>
> GENERAL PROTECTION FAULT IN MSBORG32.DLL
> --
> Donald Lee ([EMAIL PROTECTED])
> Associate Enterprise Engineer
> MCSE, Compaq ASE, ACT, A+, TCT, HP
>
> _
> Join the worlds largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
HttpRequester.java
Description: Binary data
HttpOutputWriter.java
Description: Binary data
HttpConverter.java
Description: Binary data
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
Accessing Manager app through URLConnection
Ok, how can I go about accessing the Manager app through a URL connection? Its currently generating a 401 error code, and I know the reason is because of the role stuff...how can I programatically assign a role? Or is there a way I can pass the user/pwd info along with the url poarameters somehow? I'd greatly appreciate some ideas on this... THanks, Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- "What a great time to be a(n employed) Geek" -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
Tomcat 4 & Runtime.exec()?
Can anyone tell me why the Runtime.exec() call in the following piece of
code runs fine standalone, but blows chunks in Tomcat 4?
File path = new File("E:/WebProjects/lutris/cvs/Barracuda/src");
String[] args = new String[] {"ant.bat","admin.sample1"};
try {
Process p = Runtime.getRuntime().exec(args, null, path);
StringBuffer sbOut = new StringBuffer(1000);
BufferedReader br = new BufferedReader(new
InputStreamReader(p.getInputStream()));
while (true) {
String s = br.readLine();
if (s==null) break;
System.out.println(s);
}
br.close();
p.waitFor();
System.out.println (sbOut.toString());
System.out.println ("Exit status: "+p.exitValue());
} catch (Exception e) {
System.out.println ("Unexpected error executing cmd:"+e);
}
Like I said, it works fine when run as an application. But in Tomcat, I get
the following stack trace:
Path: E:\WebProjects\lutris\cvs\Barracuda\src (exists=true)
Args[0]: ant.bat
Args[1]: admin.sample1
Unexpected error executing cmd:java.io.IOException: CreateProcess: ant.bat
admin.sample1 error=2
java.io.IOException: CreateProcess: ant.bat admin.sample1 error=2
at java.lang.Win32Process.create(Native Method)
at java.lang.Win32Process.(Unknown Source)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Unknown Source)
...
...
Suggestions? Is there something I don't know about invoking Runtime.exec()
from with a servlet?
Thanks,
Christian
------
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
--
"What a great time to be a(n employed) Geek"
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
RE: Getting IIS to pick up changes to uriworkermap.properties?
Ah-ha! That explains it. Thanks much! Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Instant Messenger: ChristianSCryder Barracuda - http://barracuda.enhydra.org -- "What a great time to be a Geek" > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > he.org]On Behalf Of Ignacio J. Ortega > Sent: Monday, January 14, 2002 3:07 PM > To: 'Tomcat Users List' > Subject: RE: Getting IIS to pick up changes to uriworkermap.properties? > > > > De: Christian Cryder [mailto:[EMAIL PROTECTED]] > > Enviado el: lunes 14 de enero de 2002 22:40 > > Isapi_redirector.dll is loaded by inetinfo.exe, that's the IISAdmin > service, so you need to Restart IISAdmin Service itself, not IIS alone.. > > Saludos , > Ignacio J. Ortega > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
Getting IIS to pick up changes to uriworkermap.properties?
Hi folks, I have followed the very excellent instructions at http://members.ozemail.com.au/~lampante/howto/tomcat/iisnt/ that describe how to integrate Tomcat 4.0.1 with IIS. At this point, I have everything working, but I am observing a (hopefully) minor problem. When I want to add a new webapp to Tomcat, I modify a) server.xml to point to the new web app directory (ie e:\test99) b) uriworkermap.properties to map the request url from IIS to Tomcat (/test99) Then I cycle both Tomcat and IIS services. What I notice, however, is that the new webapp is still not accesible until I reboot: if I try to access http://localhost:8080/test99 (Tomcat direct) I can get to it, but at http://localhost/test99 (IIS) I cannot. Consequently, it seems to me that Tomcat is picking up the changes (since I can access the app on its local 8080 port), but IIS is not. I am wondering if there is something else I need to do in order to get IIS to notice the change (short of actually rebooting *blech!*). Am I doing something stupid? Have I missed some essential piece of documentation? If anyone has any suggestions I'd love to hear them... Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Instant Messenger: ChristianSCryder Barracuda - http://barracuda.enhydra.org -- "What a great time to be a Geek" -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
ANN: Barracuda Beta 2
Hi folks, Just a brief announcement to let you know that the Beta 2 release of Barracuda is now available at http://barracuda.enhydra.org. If you never work with Servlets, JSPs, XML or DOM, delete this email now. For those of you who are still reading and wonder "What the heck is Barracuda?", you can learn more about it here: http://barracuda.enhydra.org/what_the_heck_is_barracuda.html Enjoy! Christian ---- Christian Cryder [[EMAIL PROTECTED]] Barracuda - MVC Component Framework for Webapps http://barracuda.enhydra.org "What a great time to be a Geek"
ANN: Barracuda Beta 1
Hi folks, Just a brief announcement to let you know that the Beta 1 release of Barracuda is now available at http://barracuda.enhydra.org. If you never work with Servlets, JSPs, XML or DOM, delete this email now. For those of you who are still reading and wonder "What the heck is Barracuda?", read on. Barracuda is an open-source Presentation Framework designed to make it easier to build servlet based webapps by applying proven client-server patterns to the web development paradigm. Key features include: -DOM based templating mechanism for better separation of code from content (default implementation uses XMLC...see http://xmlc.enhydra.org) -UI component model that provides a series of server side widgets (table, list, template, etc) that make it easy to manipulate DOM structures. Strongly typed MVC interfaces just like in Swing. Support for multiple markup languages (HTML, WML, XML, etc). -Event model that provides Model 2 style flow control and allows for true event driven programming on the server. You can add listeners to components and your server-side event handler code will automatically get notified when an action occurs on the client. -Form mapping and validation framework that makes it possible to easily convert HTTP Request form parameters into first class Java objects and validate them -Localization services that extend the XMLC compiler to make it really easy to localize DOM templates and then load them based on target locale -based on the Servlet 2.2+ API (so it'll run in any decent app-server). -And of course it's open source! ;-) Full details at the website--source available under CVS, mailing list to ask questions, lots of documentation, sample apps, yadda, yadda, yadda. Enjoy! Christian -------- Christian Cryder [EMAIL PROTECTED] Barracuda - Open-source MVC Component Framework for Webapps http://barracuda.enhydra.org "What a great time to be a Geek"
