HTTP plus
I did see a reference to a "socket servlet" which touches on this. Tomcat has doe a lot in it that is very useful (to re-itterate) - Administration of sevlets on a "live" server with web interface - handling of depolyment and undeplyment - integration with IDEs and build systems (eclipse, ant, etc) (I could go on but it is a tested reliable system with a lot of goodies) We have an internal non-http messaging system gateway which routes blocks of low latency messages to applications. I would like to use Tomcat as an "application module manager" for this system. The applications in most cases desire to act as proxys between the internal messaging system and the HTTP web world for web clients so the all the HTTP goodies like apache connectors are highly desired. I am working on determining the feasbility of using tomcat for this purpose. Some questions :) - What is the absolutely minimal HTTP header required to cause tomcat to invoke a servelet for processing binary content? ie: "POST HTTP 1.0 ... " ?? - Is there a way to create a servlet to serve some other protocol (lowest level, lowest overhead) than an HTTP request? - Is there a way to have a servlet serve a persistent connection (like a telnet terminal session) - If the "default" servlet process a request and uses a field as routing information to another servlet is there any significant overhead in forwarding the request to another servlet. I know I'm stretching it a bit but this would be really useful!! Thanks! Peter K. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HTTP plus
Was this last message of mine just too naive :) Should I break it into smaller parts? Still curious :) Peter K. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
I guess I'll answer my own question here after some testing and research That is: If you override the "service()" method on servelet all you need is a "service name" and a "path" to the servlet followed by two newlines as the "minimal" header. ie: X /Z\n\n for the most minimal header. "X" being the service name and "/Z" being the path to the servlet. On reply if "service()" if you write to the response.getOutputStream() you are in essence writing directly to the connected socket unfiltered. At 18:32 2/26/2007, you wrote: Was this last message of mine just too naive :) Should I break it into smaller parts? Still curious :) Peter K. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Ok - continuing.
Is it possible to use a "GenricServlet" to do basicly this.
service(req,res)
{
for(;;)
{
readSome(req.getInputStream());
if(writeSome(req.getOutputStream()) {
req.flushBuffer();
} else {
break;
}
}
}
That is read in incomming "socket stream" and write something back
while reading in a way that takes advantage of the connection. That
is not being purely "transactionless" and bypassing all the HTTP
specific protocols after the header needed to address the specific servlet.
PK
At 20:59 2/27/2007, you wrote:
I guess I'll answer my own question here after some testing and research
That is:
If you override the "service()" method on servelet all you need is
a "service name" and a "path" to the servlet followed by two
newlines as the "minimal" header.
ie:
X /Z\n\n
for the most minimal header.
"X" being the service name and "/Z" being the path to the servlet.
On reply if "service()" if you write to the
response.getOutputStream() you are in essence writing directly to
the connected socket unfiltered.
At 18:32 2/26/2007, you wrote:
Was this last message of mine just too naive :)
Should I break it into smaller parts?
Still curious :)
Peter K.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
I understand what you are saying, however that means you also have to
re-do all the "application management" system. Deployment,
connectors, management, adminstration, thread management, load
balancing, SSL key management and configuration and many many other
infrastructure pieces that can be leveraged to manage a large complex
system. This would be a huge project (ie: the scale of creating tomcat)
So if one wants to create a web adminstratable application that has
(one or more servlet "ports" that connect with other protocols). And
has web ports to handle HTTP requests into the same system. If you
*can* do it in tomcat it would be great. If those protocols are
somewhat "transaction" based then they would fit very well into the
servlet model. I am trying to sus out the potential.
Yes you can always write a complete application manager from scratch :)
I am trying to avoid it.
Peter K.
At 06:36 2/28/2007, Georg Sauer-Limbach wrote:
If you don't want to deal with HTTP, you should
not use the Servlet API (which is the Java
abstraction of HTTP) at all. You can do the
indicated code with generic sockets, no need to
mind about Servlets altogether.
Georg
Peter Kennard wrote:
Ok - continuing.
Is it possible to use a "GenricServlet" to do basicly this.
service(req,res)
{
for(;;)
{
readSome(req.getInputStream());
if(writeSome(req.getOutputStream()) {
req.flushBuffer();
} else {
break;
}
}
}
That is read in incomming "socket stream" and write something back
while reading in a way that takes advantage of the
connection. That is not being purely "transactionless" and
bypassing all the HTTP specific protocols after the header needed
to address the specific servlet.
PK
At 20:59 2/27/2007, you wrote:
I guess I'll answer my own question here after some testing and research
That is:
If you override the "service()" method on servelet all you need
is a "service name" and a "path" to the servlet followed by two
newlines as the "minimal" header.
ie:
X /Z\n\n
for the most minimal header.
"X" being the service name and "/Z" being the path to the servlet.
On reply if "service()" if you write to the
response.getOutputStream() you are in essence writing directly to
the connected socket unfiltered.
At 18:32 2/26/2007, you wrote:
Was this last message of mine just too naive :)
Should I break it into smaller parts?
Still curious :)
Peter K.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. If this is true I want to know about this. I am so far under the impression if you needed to connect with another protocol in a servlet you could in essence (Worst case scenario) "write a server" inside a servlet using sockets. But that would require you write all the code to handle aborting startup/shutdown thread management etc etc. If I can have a "tweaked" protocol servlet as part of a multi-servlet application this would make a perfect model for the "gateway" type of application between HTTP and a non (exactly) HTTP protocol we are trying to support. Can you "write a server" inside a servlet ?? PK At 06:46 2/28/2007, you wrote: On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: > If you don't want to deal with HTTP, you should > not use the Servlet API (which is the Java > abstraction of HTTP) at all. You can do the > indicated code with generic sockets, no need to > mind about Servlets altogether. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP plus
Yes - I'm assuming J2ee facilities. At 06:57 2/28/2007, you wrote: That's certainly correct, raw socket communication is not J2EE. Peter didn't mention, however, that J2EE was a necessary precondition for his case. On the contrary, this communication with some binary messages sent over sockets cannot be made to fit in a J2EE environment easily, save these options with JCA which I don't know enough about. Georg Wayne Gemmell wrote: On Wed, 28 Feb 2007 12:36:03 +0100 Georg Sauer-Limbach <[EMAIL PROTECTED]> wrote: If you don't want to deal with HTTP, you should not use the Servlet API (which is the Java abstraction of HTTP) at all. You can do the indicated code with generic sockets, no need to mind about Servlets altogether. Excuse the naivety but I thought you couldn't open a socket with J2EE. I was told (I think on this list) that you need to use a JCA to make the connection. Regards Wayne - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP plus
At 09:42 2/28/2007, you wrote: Back to the original issue: sounds like you really need to develop your own connector to handle your proprietary protocol, rather than trying to twist one of Tomcat's HTTP or AJP connectors into doing your bidding. What we do is to be determined. What I want to do is sus out the *full*extent* of tomcat's capabilities so I know what I have to work with. We will build the (internal) sockets based protocol to optimize the abilities of what we have available :) I am interested in what you mean by "connector" by that do you mean an interface to route connections to a Tomcat managed application that will work in concert with it's thread pooling etc? Is their a special more controllable API that such connectors use to dispatch requests to servlets? Since I am working on an internal protocol in an enviroment where we also wish to use full HTTP1.1 for other URLs and interfaces into the same application(s), all the HTTP features are desired. The servlet development model, and the vast infrastructure it now is a part of, Deployers, IDE plugins, connectors, books, documentation, system loggers and monitors, developer administration, and people who know how to use all of it and other positive attributes are really fantastic assets, so we wish to leverage it as much as we can and not re-invent wheels. I will put whatever HTTP headers are required to make tomcat operate (seeking minimum compliment) but after the connection is made and routed to the proper servlet I want to drop back to a binary non-http protocol for the duration of the connection. And if possible it would improve our system architecture If I could respond to the client without having to manage a lot of session state before all the input is read (actually, before all of it is written by the client to its outgoing socket) and processed. but at least so far with reading and testing it seems the input side of the socket is killed before or when one starts writing output. If this can be controlled by HTTP headers, tomcat config, setting something in an object etc then this would be a way we could do it and I'm very VERY interested in the possibility. We have full control of the client that will be connecting directly to tomcat "worker" instances. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Servlet Lifecycle
So if a servlet is lets say in a long transaction, sending a huge data set, and the manager is wanting to "undeploy" it, Does it get notified while the long lasting servlet thread is sending data so if one wants to abort it, you can truncate writing in a controlled way and clean up the mess nicely? Or will it wait until it is done or a timeout and you get notified with uninit() after this? Of course I want notification, that leaves you enough time to be nice :) PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTP plus
OK - persistance has paid off :) I now have a little client that with a small HTTP header will connect with a servlet, and run a persistent "telnet" like session with it until either someone times out or decides to quit. The only requirement is that you initiate the connection with HTTP headers. And in 1.1 you have to use a "chunked" reply structure. if using 1.0 you don't (there might be a way around that in 1.1 too but I havn't found it :) PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Writing My Own Connector
I want to write my own "protocol handler" which I can configure as a connector. I want it to do something along the lines of AJP - packet hits in, servlet hits out. A - should I be posting this to a "dev" list? B - I want a good reference on what class I need to subclass, how to use it and what are considered this abilities "supported" features. What is the best book or doc I should look at for this? Thanks much! Peter K. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing My Own Connector
I think the existing connectors in tomcat source could be the only existing documentation :) Not a good sign for them being "officially" supported. Has anyone here made one? What I would like to do is take an AJP connector, redo it's insides to parse another format and then pass the requests off to servlets. At 15:53 3/2/2007, David Delbecq wrote: Peter Kennard a écrit : > I want to write my own "protocol handler" which I can configure as a > connector. I want it to do something along the lines of AJP - packet > hits in, servlet hits out. > > B - I want a good reference on what class I need to subclass, how to > use it and what are considered this abilities "supported" features. > What is the best book or doc I should look at for this? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing My Own Connector
would definately be someting to do. one has to wade through a lot of stuff to get to that point :) I have to find out where what defines a connector is, how it is installed and configured ... So what people are saying is "get the source and build it" as step #1 ?? At 16:38 3/2/2007, you wrote: Seems to me that looking at the differences in source between two connectors (e.g. AJP and HTTP) would be the best documentation of what you'll have to change :-) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writing My Own Connector
Thanks very much!
The big hope is all the socket connection and thread pool management
"wheel re-inventing" etc is "done" and I can do it mostly "high
level" except for the interpreting of the input protocol byte
streams. Have it do somehing like:
ProtocolConnectorThread.onListenerConnect(inputStream, outputStream)
{
try {
request = mypool.getARequest(inputStream,this);
response = mypool.getAResponse(outputStream,this);
for(;;)
{
( parse stuff in protocol header inputStream,
deal with protocol };
request.resetAndSetStuff(inputStream,stuff);
response.resetAndSetStuff(outputStream,stuff);
routeToServelet("urlName",request,response);
}
}
catch(ServletOopsException oe)
{
Oops, respond to sender "I'm Dead" on output, kill socket
}
mypool.reclaim(request);
mypool.reclaim(response);
}
At 23:03 3/2/2007, you wrote:
"Peter Kennard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> would definately be someting to do.
> one has to wade through a lot of stuff to get to that point :)
> I have to find out where what defines a connector is, how it is installed
> and configured ...
>
Well, the first thing that you need is a ProtocolHandler
(http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/coyote/ProtocolHandler.html).
Any attributes that are put into the element will be passed
JavaBean-style to your ProtocolHandler, so you can take care of
configuration that way. It is the job of the ProtocolHandler to accept
requests, manage threads, and pass the request back off to the Adapter
(http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/coyote/Adapter.html)
that Tomcat gives it. Most of the time, you will also need to implement
ActionHook
(http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/coyote/ActionHook.html)
for best results.
You mentioned something about modifying the AJP Connector. The JK AJP
Connector (the one under o.a.jk) has a plugable archatecture that may allow
you to reuse some of the bits (in particular,
ChannelSocket/ChannelNioSocket) if your protocol is close enough (or you can
change it to be :).
> So what people are saying is "get the source and build it" as step #1 ??
>
> At 16:38 3/2/2007, you wrote:
>>Seems to me that looking at the differences in source between two
>>connectors (e.g. AJP and HTTP) would be the best documentation of
>>what you'll have to change :-)
>
As of TC 6, there are 3 supported AJP Connectors, and 3 supported HTTP
connectors ;-).
>
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Detecting terminal HTTP chunk
Hmm - when reading HTTP1.1 chunked data, is there a way of detecting reciept of the terminal "0" chunk in a servlet ? Googling about, Apparently this does not report an EOD "exception" (as I would expect) because some people have been using post last chunk data for server internal out-of band information. (?) Questions: 1 - Is there a way I can detect receipt of the terminal HTTP chunk before the final "read()" which would hang and timeout otherwise (Yes I could detect an end tag or whatever and push the "problem" upstairs, but that's not the point). 2 - Is there a way (short of writing a protocol handler) to disable chunk parsing in the ServletInputStream and be responsible for my own chunk parsing ? (Ideally for me, I could access an almost raw socket read, but, I think access to that has been abstracted away) Thanks! PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Detecting terminal HTTP chunk
I guess the general form of this question is, with HTTP1.1 chunked input, how do I read "a chunk at a time", which requires I know the length of the chunk before calling "read()" so if I attempt to read more than the length of the chunk so I can process it immediately instead of waiting for subsequent input ??? (in the final chunk case there is no subsequent input.) That is without having to put in a second form of chunking inside the HTTP chunking ?? PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Detecting terminal HTTP chunk
if available() is accurately suported I guess that does part of the job, but it still doesn't let you know the last chunk you read was the last one. It is wholly dependent on the higher levels reading an end tag, which seems like a design mistake instead of getting and "end of file" or "end of data" exception. At 14:21 3/4/2007, you wrote: The servlet API does not expose these details. At best you have the InputStream to read from. (And use available() if you want to try to read without blocking (but due to buffering probably won't work anyways)) But since you can't send the response without finishing the reading of the input stream - the entire question doesn't seem to make sense. -Tim Peter Kennard wrote: I guess the general form of this question is, with HTTP1.1 chunked input, how do I read "a chunk at a time", which requires I know the length of the chunk before calling "read()" so if I attempt to read more than the length of the chunk so I can process it immediately instead of waiting for subsequent input ??? (in the final chunk case there is no subsequent input.) That is without having to put in a second form of chunking inside the HTTP chunking ?? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Detecting terminal HTTP chunk
At 23:07 3/4/2007, you wrote: But since you can't send the response without finishing the reading of the input stream - the entire question doesn't seem to make sense. If the input pipe is slow (ie: cellphone with slow pipe) and you are sending a transaction where the first part of it initiates a big operation (like a database lookup) the lookup can be happening while the rest of the data is still being read in. ie: it is useful to be able to read input in small chunks as it comes in. And the client can be tuned to chunk appropriately for the transaction(s). available() may work for this depending on buffering scheme of tomcat's protocol handler. On writing the reply if you call "flushBuffer()" it will dispatch whatever is in the buffer (HTTP chunks as ip packets) to the client even if input reading is incomplete. Doing so if you can, will reduce round trip latency and the time your socket is consumed. A gross example would be a transaction to process a large file and return it to the client. If the processing was serial then the client could be receiving the return file even before it had finished sending the source file. It seems the servelet API was not upgraded to handle incremental chunks in a flexible general manner when it was added in HTTP1.1. This is irrespective of how chunks may be juggled by any proxy or other front end. I am simply dealing with how you *can* handle them on the receiving end. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Detecting terminal HTTP chunk
At 04:53 3/5/2007, you wrote: Peter Kennard wrote: At 23:07 3/4/2007, you wrote: But since you can't send the response without finishing the reading of the input stream - the entire question doesn't seem to make sense. If the input pipe is slow (ie: cellphone with slow pipe) and you are sending a transaction where the first part of it initiates a big operation (like a database lookup) the lookup can be happening while the rest of the data is still being read in. ie: it is useful to be able to read input in small chunks as it comes in. And the client can be tuned to chunk appropriately for the transaction(s). It's not really useful for Tomcat though, given that the server is designed to be a Servlet Container rather than a multipurpose network application. Yes - it's a matter of what is *considered* useful in the context. HTTP is being forced to evolve. Tomcat mainly handles two cases: 1) read headers & THEN send response e.g. GET, 2) read headers & process body, THEN send response e.g. POST. I will let it lie after this rant - I have enough info for now, and I thank list participants for thier answers :) Right - Tomcat was initally wholly designed aroud HTTP1.0 "single IP connection hit" as a paradigm and disavowed the feature of having a bidirectional connection. IN essence HTTP made UDP out of TCP, and in the process may have inadvertantly scuttled IPV2. This was a major flaw in the initial HTTP conception and as the IETF and W3C move forward things like "Content-Disposition: chunked" have been added. which along with the evolution of HTTP proxys and load balancers has led to the absurdity of what one migh call "HTTP URL Addressed - High Speed Routers" as a major part of the infrastructure. available() may work for this depending on buffering scheme of tomcat's of ... how chunks may be juggled by any proxy or other front end. I am simply dealing with how you *can* handle them on the receiving end. Why would the servlet API need to do that, when chunking is something that happens during the response rather than the request? It *can* happen both ways as defined by W3C, just current browsers don't support it. Tomcat HAS [I might say partial] support for it in the HTTP1.1 connector now because it was "required" to build practical proxy "routers" and to load balancers. Some resources I consider a valuable part of the "Tomcat infrastructure" I want to leverage for this project. Your analysis is from the point of view of someone who's (if you'll forgive the analogy) trying to force a car to work like a canoe. In some sense yes, but then almost all uses of HTTP are doing this to one extent or another because initially HTTP was so shallowly conceived. I would say I'm trying to make a mississippi riverboat into a hydrofoil and keep the ballroom :) Given that, I'd suggest that if your app client is sending a large amount of data that can be processed in discrete chunks, you might as well split it (the request) into a series of separate smaller requests. Actually in this case is is a small ammount of data over a slow pipe but in a lot of small pieces, and in this case a "hit" becomes high overhead. The HTTP hacked on solution to a similar problem, the many-hit hyperlinked page, is to use "keep alive" and to duplicate really fat HTTP headers for hundreds of "multiplexed" hits comming back from complexly linked up pages pages of frames and tables, and have this integrated into the socket handling of both browsers and servers. If you've got control of the client you could set an X-Header that indicates it's position in the series, and another that groups them. Undestood, yes "session" ID to maintain state if that is needed. At least then you gain some robustness and your server can indicate to the client if it's missing one of the series. Yes I understand these issues *all*too* well, hence why I want to do this ;^> Having said all that, though, I'd have started from scratch or built a web service as I'm not sure what I'd really be gaining by using Tomcat. Actully a whole lot and the the people involved should be proud it is so useful robust and documented. Even if I have to write a "custom protocol" handler for the front end for some ports. Tomcat already has built a very good, administrable server side application structure, packaging scheme, remote deployment system, developer adminstration and acess scheme, application manager web ui, and a "standards based remote platform independent UI system" ie: HTTP1.1 support + jsp + libraries for use of the web desktops. And if I remain AJP complient internally I can take advantage of load balancers and a lot of other "off the shelf stuff". This includes al
Re: Detecting terminal HTTP chunk
typo, if anyone read it, I meant IPV6 :) PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Console Logging
I have been looking about :) I have a simple tomcat instance with one webapp in it. I want to turn on "high level - type" logging to the console for internal debugging messages so I know what is happening. I gather I have to put a log4j.properties file in common/classes I put one I found in a howto and nothing happend (no file or change in console output) I ideally I could turn it on/off (ie internal engine logging) in my application to braket things that are a problem. turnItOn(); doSomethingThatBreaks(); tornItOff(); Thanks in advance. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Console Logging
I did what it says here http://minaret.biz/tips/log4j.html but no results. I havn't found other decent "instructions" yet. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Console Logging
Thanks will check out after lunch. I definately want to use the log4j for our apps. I am assuming the Tomcat internals have very good debug log info like why sockets are closed or timed out etc (If I can get them activated :) I dread finding out it might be a windows sockets bug :| PK At 13:18 3/7/2007, you wrote: > I did what it says here > http://minaret.biz/tips/log4j.html > but no results. > > I havn't found other decent "instructions" yet. > PK > try this one: http://www.vipan.com/htdocs/log4jhelp.html with http://minaret... you need to install another jar... Regards. FC > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Console Logging
That is interesting, Certainly for adminstration of many apps it
would be great to have a good GUI for assigning log files to apps and
log levels.
but I can't even get any debug output yet, much less tweak
it. Everyone warns about the volume of data when it's tured to "11", but:
Where I am:
With an "out of the box" Tomcat 5.5 install on my workstation (windows XP)
I set level=ALL on every entry in conf/logging.properties
(no change to files or console print)
I tried setting them to DEBUG and it barfed saying DEBUG was in invalid value.
I set debug="10" on all the entities in the server.xml file
(likewise no change)
if I cd (catalina-home}/logs
grep DEBUG *
I get nothing. And files arn't that big. They are logging INFO
however so they are being written to.
I put the newer version log4j1.3 jars in common/lib as described in a HOWTO.
This did change something, I got less console output and less info in
the files.
I know it's looking there for catalina-base because if I change the
server.xml file changes take effect when restarted.
I tried putting in both the log4j.properties and the log4j.xml files
from the howto page, no change over putting in the jars.
I'm a bit mystified. too many different sets of instructions and
interactions I guess.
My problem is I am getting some apparently spontaneous socket
closings reported by the client and want to find out detail. All on
local host, I'm simulating a slow "server push" application with:
for(i = 0; i < 100; ++i)
{
Thread.sleep(200);
res.getWriter().println("waiting " + i);
res.flushBuffer();
}
res.getWriter().println("done!");
res.flushBuffer();
Using flushBuffer() makes "Transfer-Encoding: chunked" chunks in the reply.
My client reports the socket is closed way before the "done" is
recived in about 80% of cases. Otherwise tomcat is sending HTTP
chunks exactly as expected and to HTTP1.1 spec when it works. I
figure on the clinet I should get all the chunks up to the terminal
chunk \r\n0\r\n before the socket is closed.
I need to figure this out, it's kind of a fundamental basic thing,
I'm a bit stuck.
PK
At 12:37 3/7/2007, you wrote:
I wrote an application which allows you to modify the running log4j
configuration on the fly. It's a Struts app, and relies on the fact that
tomcat and all the apps are running out of common/lib/log4j*.jar and
common/classes/log4j.properties. However, you could add the servlet, jars,
and mappings to a single app if you wish. I have found it useful for
turning up or down logging levels on a running production system. It will
revert to your log4j.properties configuration as well, so you can easily go
back to the configured settings when you're done.
I can send you (or anyone else who is interested) the sources and/or war.
PM me off-list.
Tim
> -Original Message-
> From: Peter Kennard [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 07, 2007 10:59 AM
> To: Tomcat Users List
> Subject: Re: Console Logging
>
> I did what it says here
> http://minaret.biz/tips/log4j.html
> but no results.
>
> I havn't found other decent "instructions" yet.
> PK
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Console Logging
BTW found the bug it wasn't in tomcat ;^> but in the client :) In any case the logger info was very helpful! PK At 13:18 3/7/2007, you wrote: > I did what it says here > http://minaret.biz/tips/log4j.html > but no results. > > I havn't found other decent "instructions" yet. > PK > try this one: http://www.vipan.com/htdocs/log4jhelp.html with http://minaret... you need to install another jar... Regards. FC - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location to override global
I would actually LOVE to have errors directed to a servlet like interface to reply to the client. In my case we are going to be routing requests from a lot of mobile devices using a compressed form for traffic. PK At 14:05 3/7/2007, you wrote: This seems basic, but apparently not. A similar question has been asked recently, and there are a few posts on the web, but the answers aren't enough to solve my problem. I am trying to override the global default error page by using directives such as /catch_all_errors.html or even 404 /catch_all_errors.html If I include this in the bottom of my webapps web.xml file, it will catch 404 errors for requests under my web-app: http://myhost.com/myWebapp/thisPageDoesNotExist.html but when I modify the global deployment descripter conf/web.xml, I cannot catch top-level errors like this one: http://myhost.com/thisPageDoesNotExist.html More specifically, as a previous poster pointed out: http://marc.theaimsgroup.com/?l=tomcat-user&m=116059712510694&w=2 it will catch the errors and display a blank page, but it won't display my customized page. A related problem is that even when I display customized errors under my webapp, the error-page text displays, but loaded graphics sometimes do not (it seems to depend on the URL). At least part of my problem is that I am not sure where to locate the error page if I create one. That is, what the root directory is for the statements: /catch_all_errors.html or catch_all_errors.html Thanks. -- View this message in context: http://www.nabble.com/Location-to-override-global-%3Cerror-page%3E-tf3364166.html#a9359765 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is APR worth it (for me?)
Doesn't AJP "multiplex" traffic, that is queued up requests are "serialized" through one connection that remains connected and it switches between servlets on the receiving end? and recycles the execution thread? At 19:19 3/7/2007, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémy, Rémy Maucherat wrote: > The scalability improvement is twofold for AJP: > - when running many Apache frontend servers (each with a sizeable > number of workers), Tomcat would need a huge amount of AJP worker > threads with the java.io connector Makes sense. So, instead of a Java thread waiting in every single ajp connection, you're using one native listener thread waiting on a select(), right? It's sad that you can't do this in Java :( > - threads will only be used for actually executing requests, thus > making concurrency in business logic a bit more predictable (if you > have 2000 threads, it's ok most of the time, as long as no lock gets > contested by too many threads, in which case it's far better if you > had only 200 threads) Definitely. Unless I'm mistaken, Java threads on Linux are pthreads, which are relatively heavy. Reducing them is certainly going to reduce memory, thread counts (wrt system limits), and thread dump lengths. > It also saves memory (no surprise). Socket polling will only be used > for keepalive: during the processing of a request, the connector uses > regular blocking IO. Cool. So, it /does/ sound like something worth looking into. APR installation looks like a snap, too, so it shouldn't be painful at all. Thanks for the explanation, Rémy. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF71aP9CaO5/Lv0PARAk7yAKCmhD9Xg5yH1yb5FNSrkeuP8uc0fQCeI9i8 E2Yjiq1jJR9SNcAOMErVJjQ= =FEvG -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is APR worth it (for me?)
Hmm I woudl have thought otherwise, since after reading the protocol it seems specificly designed to support keeping connection alive. That a sender would keep a "pool" of available connections and when a hit comes in "get" one which is already connected, and push the request out, and the destination looks up the servlet and dispatches to it (until the request is complete), and when complete, releases the still open connection so the sender and can recycles it back into its pool without "disconnecting" ie: socket remains open. and there is some huristic for culling excess connections after heavy traffic may hve opened more than configured. Anyway that is what I would do ;^> If by "multiplexing" you thought interleaving routed packets for simultaneous "hits" on one pipe I didn't mean that. PK At 02:41 3/8/2007, you wrote: Peter Kennard wrote: Doesn't AJP "multiplex" traffic, that is queued up requests are "serialized" through one connection that remains connected and it switches between servlets on the receiving end? and recycles the execution thread? No multiplexing on connections. Regards, Rainer At 19:19 3/7/2007, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémy, Rémy Maucherat wrote: > The scalability improvement is twofold for AJP: > - when running many Apache frontend servers (each with a sizeable > number of workers), Tomcat would need a huge amount of AJP worker > threads with the java.io connector Makes sense. So, instead of a Java thread waiting in every single ajp connection, you're using one native listener thread waiting on a select(), right? It's sad that you can't do this in Java :( > - threads will only be used for actually executing requests, thus > making concurrency in business logic a bit more predictable (if you > have 2000 threads, it's ok most of the time, as long as no lock gets > contested by too many threads, in which case it's far better if you > had only 200 threads) Definitely. Unless I'm mistaken, Java threads on Linux are pthreads, which are relatively heavy. Reducing them is certainly going to reduce memory, thread counts (wrt system limits), and thread dump lengths. > It also saves memory (no surprise). Socket polling will only be used > for keepalive: during the processing of a request, the connector uses > regular blocking IO. Cool. So, it /does/ sound like something worth looking into. APR installation looks like a snap, too, so it shouldn't be painful at all. Thanks for the explanation, Rémy. - -chris - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple Instances on one Machine
I have a related issue. (should the be a separate thread?) I had two instances of Tomcat5.5 on a windows XP Pro Workstation. And I had a "batch" file I got off the web to launch the second instance using a shared CATALINA_HOME but each with a different CATALINA_BASE When I upgraded to Tomcat6 it broke the startup. I tried to modify it by changing paths and the like but it failed. Anyone have an updated method for doing this? PK At 09:55 3/8/2007, you wrote: > From: Rahul [mailto:[EMAIL PROTECTED] > Subject: Multiple Instances on one Machine > > I have two webapps "a" and "b" with their respective web.xml > files in $CATALINA_HOME\webapps\WEB-INF. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keep Alive handling
for HTTP1.1 (in tomcat 6) Does tomcat handle keep alive (ie: keeping a connection open for subsequent requests) If so under what circumstances is the connection closed (or kept open)? Sending chunked content, with a terminal "\r\n0\r\n" will cause the connection to be disconnected. As does only a termainal "\r\n0" In both cases following this I am then attempting to write the next HTTP header set for the next request from the client. ie: POST /url/ HTTP1.1 ... PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BUG? - Mysterious "chunked" behavior
I have some real mysterious behavior, it seems the first chunk just doesn't
make it into the output. Doesn't matter how long or short it is.
Seems like a BUG unles I'm doing something wrong.
/* in my real tiny test servlet */
public void service( ServletRequest req,
ServletResponse res)
throws IOException, ServletException
{
java.io.OutputStream os = res.getOutputStream();
for(int i = 0; i < 5; ++i)
{
String txt = "Some Text " + i + "\n";
os.write(txt.getBytes());
os.flush();
}
}
/ the results in a purely socket based client (ie exactly what is sent
back - all appropriate except the "Some Text 0" is plain missing !!! */
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Sun, 11 Mar 2007 02:22:52 GMT
c
Some Text 1
c
Some Text 2
c
Some Text 3
c
Some Text 4
0
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive handling
At 19:50 3/10/2007, you wrote: The "0" is the hex digint "Zero" the "terminal EOD" chunk is defined in HTTP1.1 as a chunk with a length of 0. This is what terminates the data for the current request. I tried "explicitly" putting in the keep alive header, though it is deprecated in HTTP1.1 and is the default value if no header is supplied. As expected this has no (different) effect. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, Peter Kennard wrote: > for HTTP1.1 (in tomcat 6) > > Does tomcat handle keep alive (ie: keeping a connection open for > subsequent requests) > > If so under what circumstances is the connection closed (or kept open)? > > Sending chunked content, with a terminal "\r\n0\r\n" will cause the > connection to be disconnected. > > As does only a termainal "\r\n0" What is the "0" for? Are you sending the "connection: keep-alive" header? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF81Jm9CaO5/Lv0PARAjzxAJ4o4Er8VnA/qe8uOwzwkXfBYHOTIgCghtHu k1uq0TlPyEMa4oXX7clx5Rs= =wIZy -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
That is not an error, the last item in the (for(;;here)) is executed after the loop code is executed - the "side effect" only has effect within the for statement. (;;(side effect only visible inside statment in here)) ie: for(;;++i) ad for(;;i++) are equivalent ie: for(;;val = ++i) ad for(;;val = i++) are *NOT* equivalent At 05:36 3/11/2007, you wrote: Hi! You have a little error, you are using ++i instead of i++ on: for(int i = 0; i < 5; ++i) The first iteration is a 1 because the increament is done before instead of after the looping. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
Have you checked the result with a hex editor or anything like that? Is it possible that txt.getBytes() in the first loop iteration is giving you some text with a CR in it? It so, your terminal could be overwriting I am reading a socket directly in a test client. No data of any kind comes in representing the first chunk flushed. Even if it was "invisible" it would still need to be preceeded by the "hex digits\r\n" for the chunk's length. (I originally spotted this because I was parsing a binary upload and it was missing the first chunk - the text version is an emailable reproducable illustration. I can understand that this could be a specified behavior Like: "to force output into chunked mode, flush a one byte (or more) record as the first write, it will be discarded, and subsequent chunks will be written in chuked mode" But I have found no references to this behavior (or bug report for it) anywhere. PK At 10:42 3/11/2007, you wrote: Have you checked the result with a hex editor or anything like that? Is it possible that txt.getBytes() in the first loop iteration is giving you some text with a CR in it? It so, your terminal could be overwriting the text with the next line of output, even though it's really there. Just a shot in the dark. Try piping wget through od and see what falls out. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive handling
What if you use a non-chunked request? You asked already and the response was that TC basically doesn't handle chunked requests. TC handles chunked requests in all ways except that it doesn't have a methodology in the servlet API (EOFException etc) for notifying you if you try to read beyond EOD. Chunking is a requirement of HTTP1.1. TC appears at least from what I can tell. to always close the socket on completion of a request - unless I am missing some critical configuration item or doing something that disables it. Anyone know where exactly what it does with keep-alive under what circumstances is documented? (Yes I know if I tackle the big job of understanding the source as if I wrote it I can figure it out) but I mean a "specification" that is a bit easier to get aquainted with :) Thanks PK At 10:30 3/11/2007, you wrote: Well, "Connection: close" is supposed to cause the server to close the connection after the request has been fulfilled, but it looks like your experience is that TC closes the connection no matter what. What if you use a non-chunked request? You asked already and the response was that TC basically doesn't handle chunked requests. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
If you file a bug for this, or for the "issue" you describe in your other thread, I will immediately resolve them as invalid, obviously. Curious you mean by this? What is obvious? Tomcat 5.5 and 6 do make "chunked" replys to HTTP1.1 requests that do not explicitly set content-length if one flushes the buffer. I want to know what the proper manner is to use this feature and make sure it works from a servlet by testing it. I'm trying to be nice and comform to standards, proxy protocols, connectors etc. Are you saying there is no proper manner ?? Is this a partially implemented "alpha" feature intended to be completed in a future version? PK At 12:39 3/11/2007, you wrote: Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
No problem :) I found if you flush before any data is written, it will immediatly commit the headers, and write a "terminal" chunk of length 0. Which is a reasonable behavior. In the case of a fat upload or page where one doesn't know the exact length before starting and wants to avoid allocating a huge buffer, one would want to use the chunked response. PK At 15:13 3/11/2007, you wrote: Hi! Yes ofcourse, you are right, I was to hasty. Does it work if you add an os.flush() before the loop? /Per Jonsson Peter Kennard skrev: That is not an error, the last item in the (for(;;here)) is executed after the loop code is executed - the "side effect" only has effect within the for statement. (;;(side effect only visible inside statment in here)) ie: for(;;++i) ad for(;;i++) are equivalent ie: for(;;val = ++i) ad for(;;val = i++) are *NOT* equivalent At 05:36 3/11/2007, you wrote: Hi! You have a little error, you are using ++i instead of i++ on: for(int i = 0; i < 5; ++i) The first iteration is a 1 because the increament is done before instead of after the looping. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
Curious you mean by this? What is obvious?
It's quite simple. You've made a number of claims in your two threads,
every time supposedly verified by yourself, and for every one of them,
I can tell you that the opposite is actually true. So there's really
nothing to talk about ...
I have to oppolgise here. I thought I had tested the case of flush()
after writing no data and returning - pardon. It only returns a 0
length chunk if I flush once after writing some data. If I flush
once with no data it writes nothing and the client times out
expecting a chunk length (which I would consider another bug) I would
think it should ignore all zero length flushes, and wait to write the
terminal chunk when service() returns.
A complete simple test (which I actually ran just now) and it's
results are below - this is easily reproducable Hopefully this will
make the cut :)
Unless dropping the first data filled chunk is defined as proper and
documented, and supported, behavior, I would consider this a bug.
The servlet:
public void service( ServletRequest req,
ServletResponse res)
throws IOException
{
try
{
req.getInputStream();
java.io.OutputStream os = res.getOutputStream();
os.flush();
os.write("Line Of Text 0\n".getBytes());
os.flush();
os.write("Line Of Text 1\n".getBytes());
os.flush();
}
catch (Exception e)
{
System.out.println("servlet: exception! " + e);
}
}
The above when hit by client returns:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Sun, 11 Mar 2007 22:44:02 GMT
f
Line Of Text 1
0
The same servlet with:
os.flush();
os.write("Line Of Text 0\n".getBytes());
os.flush();
// os.write("Line Of Text 1\n".getBytes());
// os.flush();
When hit by client returns:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Sun, 11 Mar 2007 22:44:54 GMT
0
The same servlet again with:
os.flush();
// os.write("Line Of Text 0\n".getBytes());
// os.flush();
// os.write("Line Of Text 1\n".getBytes());
// os.flush();
When hit by client returns:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Sun, 11 Mar 2007 22:29:12 GMT
client: exception java.net.SocketTimeoutException: Read timed out
Peter K
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
to the actual behavior of Tomcat. The 3 examples you have given here do work as expected. On what version? - I have a plain vanilla install of Tomcat 6.0 on a windows XP Pro machine using the sun jdk (build 1.5.0_11-b03) I am connecting through an HTTP1.1 connector with the default initiall configuration via "localhost". No other servlets are deployed on this instance. - Are the results I get from those 3 examples "expected" ? - If not, why do you think this might be happening? The client is sending this minimal request: POST /Test/ HTTP/1.1\n Host: localhost\n Transfer-Encoding: chunked\n \n ... (I can read all the data uploaded just fine from the servlet, except the read hangs and times out if I don't stop before the "terminal" 0 chunk length chunk is encountered ) I'm really not trying to be a pain in the butt, just figure it out. Peter K. At 21:16 3/11/2007, you wrote: On 3/12/07, Peter Kennard <[EMAIL PROTECTED]> wrote: Unless dropping the first data filled chunk is defined as proper and documented, and supported, behavior, I would consider this a bug. As I said in my previous post, so far, none of your claims correspond to the actual behavior of Tomcat. The 3 examples you have given here do work as expected. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
The exact tomcat version I have installed is 6.0.10 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
Aaack - I really REALLY have to oppolgize. One of the people I manange gave me the dumper client, and I went through it and the problem is there :| I'm really really sorry if I caused any flamage and wasted anyone's time. I respect you people for hammering on me about it. I'll try to audit things a bt more before posting in the future. I stuck my neck out and am now under some pressure to prove the tomcat Apache infrastructure is an appropriate choice for a big project. I am still conviced it is appropriate. Peter K. At 22:29 3/11/2007, you wrote: > - Are the results I get from those 3 examples > "expected" ? I actually tried to reproduce your experience. wget, FireFox etc. - all these HTTP-clients don't have any problems with tomcat. What HTTP-client are you using? Is it self-written maybe? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUG? - Mysterious "chunked" behavior
Not that anyone cares, but the "apparent" lost chunk problem was caused by the header scanner in the dumper client. He created an InputStreamReader() and it apparently reads exactly two lines ahead into it's buffer. Since my test case was "one line" per chunk it would reliably drop (have in its buffer) the first chunk's length, and the following one text line. I'm sorry for wasting anyone's time. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive handling
Does Tomcat support Keep Alive, as a stand alone server, for multiple Client POST requests to different servlet paths where both request and response are "Transfer-Encoding: chunked"? Is there a definition somewhere of when tomcat will drop a connection when keep-alive is specified? Thanks. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive handling
Anyway - I answered my own question. I wrote a test, Keep Alive works fine with chunked content. If anyone wants the test code let me know. (should I post it?) It is small - about 150 lines worth, all java. PK Does Tomcat support Keep Alive, as a stand alone server, for multiple Client POST requests to different servlet paths where both request and response are "Transfer-Encoding: chunked"? Is there a definition somewhere of when tomcat will drop a connection when keep-alive is specified? Thanks. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive handling
I answered my own question here: The client must send the *complete* sequence "\r\n0\r\n\r\n" or tomcat *will* hang attempting to read the last "\r\n" after the last "zero length chunk" No one including myself caught this. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep Alive handling
At 15:33 3/12/2007, you wrote: > Anyway - I answered my own question. > I wrote a test, Keep Alive works fine with chunked content. So... what was the problem? For days you've been railing against Tomcat for not supporting this properly. Is there something that you overlooked? - -chris Partly too much caffeine, too little sleep, and too much pressure :) I went out on a limb with only partial knowledge to specify Tomcat as a great solution to not having to write from scratch a server side application management and request routing system (that is what Tomcat is) - and I have had to get test modules of all the glue pieces working so the other people involved can start working. I am now highly content with that decision. I hope I didn't rail against tomcat too much on this thread, the reason I'm here is I respect it. I only wanted someone to say yes or no to whether it supported KeepAlive with chunked posts or not and wondered if I was doing something stupid causing it to disconnect. And yes, I was overly distracted and irritated by "noise" like "why would you want to do that" etc, Knowing this was all added to HTTP1.1 for a lot of good reasons, to support exactly what we are doing. If I were a diplomat we'd probably all be in a nuclear fallout zone :) As for why it didn't work, I was dealing with some related things: For "not detecting terminal chunk" from a client. The client must send the *complete* sequence for the termial chunk: "\r\n0\r\n\r\n" or tomcat *will* hang and time out attempting to read the last "\r\n" after the last "zero length chunk" of data, and not report "end of file". No one including myself caught this. Keep alive was related, in it would abort and close the socket if the last "\r\n" after the zero length chunk wasn't present when the next header was written. Thanks for asking, Everything works now. Peter K. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can one map a servlet to a specific connctor?
On a stand alone tomcat with more than one connector (port) Is it possible to map a servlet to only one or a subset of connectors? Thanks PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can one map a servlet to a specific connctor?
I guess a corrollary question to this would be. Can I determine the connector port connected to for a request from service() I don't see it in the servlet API but am willing to access somthing tomcat specific. PK At 21:57 3/12/2007, you wrote: On a stand alone tomcat with more than one connector (port) Is it possible to map a servlet to only one or a subset of connectors? Thanks PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can one map a servlet to a specific connctor?
Thanks - I assume "any way you want" would include the port? I'll have to dive more into Filters. At 01:15 3/13/2007, you wrote: > From: Peter Kennard [mailto:[EMAIL PROTECTED] > Subject: Can one map a servlet to a specific connctor? > > On a stand alone tomcat with more than one connector (port) > Is it possible to map a servlet to only one or a subset of connectors? No, but you can use a filter or valve to restrict access any way you want. - Chuck - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can one map a servlet to a specific connctor?
Damn! I missed that :) Thanks. I assume this is taking it from where the hit arrives in at the server and not the HTTP headers passed in (which could be anything) At 01:32 3/13/2007, you wrote: > From: Peter Kennard [mailto:[EMAIL PROTECTED] > Subject: Re: Can one map a servlet to a specific connctor? > > Can I determine the connector port connected to for a request from > service() I don't see it in the servlet API but am willing to access > somthing tomcat specific. ServletRequest.getServerPort() is inherited by HTTPServletRequest. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can one map a servlet to a specific connctor?
I Verified this returns the port indicated by the client in the header. Not the port the request was recieved by at the tomcat instance. Appropriate for a client to send and passed through by proxys, remappers, front ends etc. but not to determine where it ends up. PK At 07:23 3/13/2007, you wrote: Damn! I missed that :) Thanks. I assume this is taking it from where the hit arrives in at the server and not the HTTP headers passed in (which could be anything) At 01:32 3/13/2007, you wrote: > From: Peter Kennard [mailto:[EMAIL PROTECTED] > Subject: Re: Can one map a servlet to a specific connctor? > > Can I determine the connector port connected to for a request from > service() I don't see it in the servlet API but am willing to access > somthing tomcat specific. ServletRequest.getServerPort() is inherited by HTTPServletRequest. - Chuck - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can one map a servlet to a specific connctor?
This could be the ticket! At 11:53 3/13/2007, you wrote: You could configure proxyPort in your to some value that you could use as a flag for your particular environment. This will override the header value returned by getServerPort(). Don't know if there would be any undesirable side effects. - Chuck - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can one map a servlet to a specific connctor?
Try ServletRequest.getLocalPort() rather than getServerPort(). Yes exactly, thanks - that is an addition to the api after the book I read :) eclipse auto-complete and the sun website is your friend :) * Part of all these questions is I am looking to implement a servlet subclass which will "auto register" itself with an upstream front end (maybe AJP does this?) so ideally I would want to be able to query what URI "host,port,path" would access the proper connector and servlet when it's "init()" is called so I can pass it to upstream to the front-end router. Of course at this time no request has been recieved. I guess I could do it by parsing the server.xml or putting in rendundant per servlet initParameters but that makes me queasy, I like the thing itself to propagate it's own state changes :) PK At 11:58 3/13/2007, you wrote: > From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] > Subject: RE: Can one map a servlet to a specific connctor? Try ServletRequest.getLocalPort() rather than getServerPort(). - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is better one or more Tomcat instances per machine
Heh - ask Murphy about that :) just spawn a thread set priority high and loop forever. At 10:23 3/14/2007, you wrote: On 14/03/2007, at 3:17 PM, Peter Crowther wrote: From: Leon Rosenberg [mailto:[EMAIL PROTECTED] There is no real advantage in multi-instancing. A minor advantage is that if you allocate one webapp per container, if one webapp fails it only takes down its own container. Well-coded webapps "should" never cause this - and, of course, we all manage completely bug-free webapps all the time, don't we? :-) Actually, according to the JSP spec, one Webapp is not allowed to effect the other, so if you use Tomcat, one Webapp can not take out the other... :-) Cheers Andrew - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stalled Servlet Handling?
Curious with the talk about reliability. Socket timouts will abort waiting on reads and writes that take too long. But if lets say a servlet takes an overly long time to process something without reading or writing, is there a high priority "watchdog" thread in tomcat which will monitor how log a servlet has been "running" without having made a read or write, and force it to abort if it exceeds it's quota? If so is the time allowed configurable? PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for makeing Invoker harder to user
I am a newbee here but as a work around, I would think you could have a "master" servlet and it could scan and load all the servlets in the directory into a map, and then dispatch requests to them from "/*" (having them properly initialized in another question) I would be interested in the official answer :) At 18:19 3/14/2007, you wrote: I recently installed Tomacat 6.0 and see that I now need to make my web application privalaged in order to use InvokerServlet to allow users to execute arbitrary servlets. This seems to continue a trend that may eventually result in Invoker being widthdrawn. My question is why is allowing execution of arbitrary servlets so discouraged. In my opinion JSPs are essentially servlets with a differnt deployment convention and there is no prohibition on running jsps without "registering them." I like to build web applications with hundreds of servlets and I prefer not to explicitly define each one in web.xml. Is there any sanctioned method of doing this in a tomcat world? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for makeing Invoker harder to user
At 20:38 3/14/2007, you wrote: http://tomcat.apache.org/faq/misc.html#evil -Tim All very good points escpecially since it will load classes outside the webapps sandbox. Definately evil. What I would probably do in the large # of servlets situation for a single webapp during development is generate the web.xml file as part of the build process and have the build scan the proper source directory and create it dynamicly before deployment. Alas hard to do in ant without scripts but would make development easier. PK Paul Mendelson wrote: I recently installed Tomacat 6.0 and see that I now need to make my web application privalaged in order to use InvokerServlet to allow users to execute arbitrary servlets. This seems to continue a trend that may eventually result in Invoker being widthdrawn. My question is why is allowing execution of arbitrary servlets so discouraged. In my opinion JSPs are essentially servlets with a differnt deployment convention and there is no prohibition on running jsps without "registering them." I like to build web applications with hundreds of servlets and I prefer not to explicitly define each one in web.xml. Is there any sanctioned method of doing this in a tomcat world? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Explicit header definition
If I want to remove or alter headers that are the "default" for a specific servlet, webapp or instance of tomcat, how might I? Either programmtically or in a config file. ie: - remove or replace the "Date:" header. - remove or replace the "Server:" header. The reasoning is for servicing a special client's requests. I would still want other "browser" serving servlets in the same tomcat instance to use the normal headers. Thanks. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explicit header definition
Does no commnent on this mean: "This is not possible"? or: "Of course, it is obvious you can, as stated *here*"? PK At 15:24 3/16/2007, you wrote: If I want to remove or alter headers that are the "default" for a specific servlet, webapp or instance of tomcat, how might I? Either programmtically or in a config file. ie: - remove or replace the "Date:" header. - remove or replace the "Server:" header. The reasoning is for servicing a special client's requests. I would still want other "browser" serving servlets in the same tomcat instance to use the normal headers. Thanks. PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explicit header definition
It might mean don't hi-jack threads. Mark ??? I thought I created a new one for this question. (different Subject:) At 10:57 3/18/2007, you wrote: Peter Kennard wrote: > Does no commnent on this mean: > > "This is not possible"? > or: > "Of course, it is obvious you can, as stated *here*"? > > PK - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explicit header definition
Thanks - is there a good doc around on "howto write a tomcat filter" :) ? It sure would be nice to have default headers defined in web.xml :) PK At 16:55 3/18/2007, you wrote: for each servlet / jsp where you want to change the default headers, write a filter, which changes the headers, include it into the web-app's web.xml and you're done. hth - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explicit header definition
I found this: http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters.html - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Explicit header definition
It looks like a Filter receives the same ServletResponse object as what is passed back from the servlet. Are their methods on that that allow you to access the Date: and Server: headers (or the whole big header string)? PK At 16:55 3/18/2007, you wrote: for each servlet / jsp where you want to change the default headers, write a filter, which changes the headers, include it into the web-app's web.xml and you're done. hth - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom error page on Tomcat 6
A refinement on this question I am interested in, that isn't so googleable :) Can one make a class that spits out the error page that recieves the "code number" as input, (and/or maybe an Exception handle if the servelet threw an exception which caused the error) and an OutputStream to write back to the requester on? That would be really really nice, and totally genrally customizable :) PK At 12:40 3/20/2007, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/03/2007, at 5:28 PM, Hoa Doan wrote: How do I set up a custom error page in Tomcat 6? Hoa, Stupid question... Have you tried entering "Custom error page on Tomcat" into Google? Grrr Andrew - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Custom error page on Tomcat 6
At 16:58 3/20/2007, you wrote: > From: Peter Kennard [mailto:[EMAIL PROTECTED] > Subject: Re: Custom error page on Tomcat 6 > > Can one make a class that spits out the error page that recieves the > "code number" as input, (and/or maybe an Exception handle if the > servelet threw an exception which caused the error) and an > OutputStream to write back to the requester on? Much of it, and in a hurry :) Sometimes "spec" docs often leave specific implementation details "ambiguous" or TBD and often hard to decypher simple answers to things from :) Thanks for the link! "I think yes it is covered in section 9.9" ? Or "I don't think so it is covered in section 9.9" ? Have you read the servlet spec? This is covered in section 9.9: http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html - Chuck - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comet in tomcat
Curious - with Comet I assume you can now have multiple servlet requests share a single thread if they are written cooperatively? I have just written a "client side" that does this with NIO. I am working on a system were a lot of small requests and body chunks are being processed. PK At 10:11 3/22/2007, you wrote: On 3/22/07, Vincent Demay <[EMAIL PROTECTED]> wrote: Hi all, I'm working on server side pushing integration in Wicket, and I saw Tomcat6 implements comet : http://tomcat.apache.org/tomcat-6.0-doc/aio.html Have you got a complete example of an application using cometProcessor? No real application to show off. How can I use NIO connector? Yes (it's written on the page). Is there an implemantation of the Bayeux protocol? No. I don't know which of these protocols will emerge at this point as "the" standard (any opinion on this ?). I think a base servlet could be included if one was contributed. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
