tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob DeRemer <>
Subject RE: HOW TO: create custom Tomcat 6 connector to do port sharing
Date Thu, 30 Jun 2011 11:46:07 GMT
I'm not sure on the XMPP over HTTP, since we require the real-time always-on connectivity provided
by XMPP.  I'll have to see exactly what XMPP over HTTP does under the hood.  We can't afford
to have our XMPP connections doing long-polling or anything.


-----Original Message-----
From: Pid [] 
Sent: Thursday, June 30, 2011 3:45 AM
To: Tomcat Users List
Subject: Re: HOW TO: create custom Tomcat 6 connector to do port sharing

On 30/06/2011 02:10, Bob DeRemer wrote:
> Chris,
> Thanks for the feedback.  I haven't come across squid yet, so I will take a look.  With
regard to HTTP proxying, no, I don't want to do HTTP proxying.  I would like to insert a TCP-based
NIO request router in place of Tomcat's Connector.  Specifically, I would like to do something
similar to the Netty Port Unification sample, but with HTTP AND XMPP protocols.  Netty has
the ability to inspect the incoming request and then get outta the way - adding the appropriate
Channel for processing the request.  
> The problem I'm facing is that we're using Tomcat as our App Server and we can't easily
replace that with a non-servlet based solution at this point.   As a result, I was trying
to determine if there is a way to create some type of Tomcat extension that where I could
do the initial request routing and pass HTTP request on to the Tomcat's plumbing without running
the built-in HTTP connector(s).

You'd have to write your own connector implementation, or hack an existing one - in Tomcat
7.0 there's some work being done to consolidate the connector code, so you'd be wise to start

Is XMPP over HTTP a possibility, and if so could the applicable code run inside a Servlet?

Sounds like a 'square peg, round hole' type situation...


> Thanks,
> Bob
> -----Original Message-----
> From: Christopher Schultz []
> Sent: Wednesday, June 29, 2011 2:51 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port 
> sharing
> Bob,
> On 6/29/2011 1:10 PM, Bob DeRemer wrote:
>> I've scoured the net for information on how to do port sharing within 
>> the context of a Tomcat Servlet-based web application process.
>> While there's some discussion, there still doesn't appear to be any 
>> solutions [YET] - that I could find yet.
>> What I need to do is the following:
>> * receive both HTTP and XMPP traffic on a single port [either 80 or
>>   443 - depending on security configuration]
>> * route the HTTP traffic to Tomcat's HTTP Connector [or
>>   sub-processing component] if possible
>> * route the XMPP to an embedded Vysper server
> All of the above should be doable using something like Squid. Does Squid do pretty much
>> * ALL running in the context of a single Tomcat Server process
> Oh.
> You want Tomcat to do HTTP proxying? AFAIK, nobody has done that. Most people who want
HTTP proxying just use some other web server out in front of Tomcat (like Apache httpd, Squid,
Nginx, lighttpd, HTTP lb, etc.). I have to imagine that at least one of those products can
do content-detection to determine where to route messages.
> Does it /have to/ be Tomcat-based?
>> This will enable us to leverage the power/investment in our servlet 
>> infrastructure and Vysper XMPP all together without having to open 
>> multiple ports.
>> If this is possible in either Tomcat 6 or Tomcat 7, please let me 
>> know how I should go about this:
>> * doing some custom extension in Tomcat (i.e. custom Tomcat
>>   connector that uses Netty for example)
>> * or, some other approach ???
> If you want to brute-force it, you could write a servlet Filter (or, better yet, a Tomcat-specific
Valve that runs before the request is mapped to a webapp) to intercept the messages and proxy
them over to your other service(s). You'll have to do the HTTP proxying yourself, though.
>> please advise on how you would recommend achieving our goal.
> Honestly, I'd look for a non-Tomcat-centric solution because it's probably already been
built elsewhere.
> -chris

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message