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:51:30 GMT
Very well stated and completely understood.  My gut is already telling me that trying to customize/extend
Tomcat in this way is way outside the scope of how Tomcat was designed or intended to be used.
 And, I would bet you're right with regard to parts of the Tomcat architecture having certain
"HTTP expectations".

Thanks again for your risk assessment - this will help in making our decision on how to move


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


To round up what I am trying to say :

Tomcat is a java servlet engine.  In the principle, there is nothing that says that it cannot
handle protocols other than HTTP/HTTPS, and run servlets which handle other kinds of messages
than HTTP/HTTPS messages.
However, my general impression is that
1) this is not being done very often
2) therefore, even apart from the Connectors, there may be quite a few aspects in Tomcat which
are HTTP(S)-centric, and which have not really been investigated a lot with
non-HTTP(S) messages.
For example, there was a discussion recently on this list, concerning "HTTP 100 Continue"

  status codes, and if I remember correctly this implied that a Listener should be configured
at the level of the Connector, and it also implied that this would trigger the immediate parsing
of request headers as soon as a request came in.
Now I can quite easily imagine that this could be much more complicated if some requests which
come in, are non-HTTP(S).

In summary, I have the feeling that creating a "discriminating Connector" which would dispatch
HTTP(S)/XMPP requests as appropriate, could just be the tip of the iceberg, and that you could
find yourself sucked into making many more changes than what you imagine at first.

Now take this with a grain of salt, since I am neither a java nor a Tomcat expert.  I just
happen to remember the classic line which says that "90% of a software project is done in
90% of the time; the remaining 10% also."

Bob DeRemer wrote:
> Hi Andre,
> Yes, XMPP typically uses port 5222, but is capable of using 80/443 as well.  If we're
able to share a port, it solves various IT administration issues when deployed in corporate
environments.  In addition, it will enable us to have a single server process and ultimately
a simpler overall architecture because we won't have to configure/manage 2 separate server
> I'm still not sure this is feasible or the best way to go, but it's worth the investigation.
 Given a lot of work I've done on the Microsoft side of things, their WCF infrastructure provides
a TCP port sharing service, which is somewhat similar in nature to what we're looking to do.
 At the end of the day - both HTTP and XMPP are TCP-based.  So, if I can front a single port
for the incoming TCP request and then route it to the appropriate protocol-specific endpoint,
there would be some significant benefits to us architecturally because we are not forced to
break the functionality into 2 separate applications - unless we wanted to.
> That said, if I can find a solution, we'll have to validate the performance and stability
- no doubt.
> Thanks,
> Bob
> -----Original Message-----
> From: André Warnier []
> Sent: Wednesday, June 29, 2011 3:30 PM
> To: Tomcat Users List
> Subject: Re: HOW TO: create custom Tomcat 6 connector to do port 
> sharing
> Pid wrote:
>> On 29/06/2011 19:51, Christopher Schultz wrote:
>>> Honestly, I'd look for a non-Tomcat-centric solution because it's 
>>> probably already been built elsewhere.
>>> -chris
>> Why is opening another port a problem?
> +1
> I do not know XMPP, but from the original OP description it sounds 
> like a protocol which uses its own transport protocol, and normally 
> some other standard port than 80/443. (*)
> Without even going into what kind of issues you may encounter at the Tomcat level when
trying to process requests/responses which are not HTTP/HTTPS, I would also think that if
you mix 2 different protocols on the same port, you will be forcing whatever equipment/software
which separates and dispatches them, to look *inside* each TCP packet to determine which protocol
this one is about.  That in itself will introduce quite a bit of overhead.
> Then again, if the connection is (sometimes) over SSL, that would also probably mean
that the packets have to be decrypted, even before their HTTP/XMPP nature can be discriminated.
> Looking at XMPP in Wikipedia, it looks like there is something called "XMPP over HTTP
transport".  Is that what the OP has in mind ?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message