You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Deepak Sharma <De...@NIIT.com> on 2004/01/20 07:14:23 UTC
problem with getParamater in relation to character encoding.
I m not able to display japanese characters in the browser because of the
problem with getParamater in tomcat which does not autmatically encode
the request string in the charset set for the page.
I m on the lookout for a patch related to this or ny pointers to solve this
problem.
I do not want to use this piece of code as it'll need me to do a lot of code
change.\
"decode_str = new String(str.getBytes("8859_1") ,"UTF-8");"
Please help me out with this.
Regards,
Deepak Sharma.
----------------------------------------------------------- NOTICE
------------------------------------------------------------
This email and any files transmitted with it are confidential and are solely
for the use of the individual or entity to which it is addressed. Any use,
distribution, copying or disclosure by any other person is strictly
prohibited. If you receive this transmission in error, please notify the
sender by reply email and then destroy the message. Opinions, conclusions
and other information in this message that do not relate to official
business of NIIT shall be understood to be neither given nor endorsed by
NIIT. Any information contained in this email, when addressed to NIIT
Clients is subject to the terms and conditions in governing client contract.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Three proposals
Posted by Filip Hanik <de...@hanik.com>.
> I'm not sure if it should happen in TC 5.0.x or 5.1.x but I'd like to
> investigate in multicast magic for topology determination.
>
> If javagroups had been ASF compatible, I could have some code for that,
> but seems we should do it by hand or via an ASF compatible license tool.
>
> The goal is of course in Cluster Group configurations, so each member
> could know others members (webapp, config). And this in conjunction
> may be with JK/JK2 successor.
why not just expand on the existing cluster implementation?
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Three proposals
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat a écrit :
> Here are some new proposals.
>
> 1) Optimization of the session implementation.
> The session is not a thread safe object. In Tomcat, the session
> implementation is partially thread safe for some reason (this has been
> like that since Tomcat 4.0, AFAIK). As a result, we can remove some
> synchronization. The code should also be simplified (fewer HashMap
> lookups - ex: remove will return the removed object if there was one, so
> removeAttribute should be a lot simpler), and avoid event object
> allocations when it is not useful. As a result of this, setAttribute
> will become much faster.
> In addition to this, I will experiment with fixing bug 26051, and will
> need to add a new endAccess method to the Session interface to do this.
> All this are rather high risk changes, and should not be ported to 4.1.x.
>
> 2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from
> me :-( I plan to use the '#' character instead, which is not useable in
> a URI.
>
> 3) New connector shutdown. There is a problem with the current Tomcat
> shutdown order. It works like this:
> - shutdown the connector
> - shutdown the webapps (which includes waiting for servlet exec to
> end, which doesn't make much sense since the connector and its sockets
> are all gone)
> This causes trouble in clustering scenarios, where requests which are
> currently being process will fail in a non predictible fashion. Shutting
> down in reverse order will not fix problems, as the connector will
> continue accepting requests (this would help a little, however).
> So I propose using the following shutdown routine:
> - notify the connector to stop accepting new requests (we can call
> this "pausing" the connector)
> - shutdown the webapps
> - shutdown the connector
> This will give requests which were being processed time to complete, and
> new requests will no longer be accepted.
> In addition, capability to pause / resume the connector will be added
> (new JMX operations), which will be useful for cluster node maintenance.
> For example, to cleanly take down a node: pause the connector, wait for
> the requests to complete (and session data to replicate), then do the
> needed maintenance, and finally either unpause the connector or restart
> the server.
>
> Comments ?
>
> I will do this after the next stable 5.0.x release (hopefully it will be
> 5.0.18 :) ), except 1) (where it's centered on one source file, mostly,
> so it'll be easy to tag the right revision).
I'm not sure if it should happen in TC 5.0.x or 5.1.x but I'd like to
investigate in multicast magic for topology determination.
If javagroups had been ASF compatible, I could have some code for that,
but seems we should do it by hand or via an ASF compatible license tool.
The goal is of course in Cluster Group configurations, so each member
could know others members (webapp, config). And this in conjunction
may be with JK/JK2 successor.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Three proposals
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> Here are some new proposals.
>
> 2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from
> me :-( I plan to use the '#' character instead, which is not useable in
> a URI.
>
> 3) New connector shutdown. There is a problem with the current Tomcat
> shutdown order. It works like this:
> - shutdown the connector
> - shutdown the webapps (which includes waiting for servlet exec to
> end, which doesn't make much sense since the connector and its sockets
> are all gone)
> This causes trouble in clustering scenarios, where requests which are
> currently being process will fail in a non predictible fashion. Shutting
> down in reverse order will not fix problems, as the connector will
> continue accepting requests (this would help a little, however).
> So I propose using the following shutdown routine:
> - notify the connector to stop accepting new requests (we can call
> this "pausing" the connector)
> - shutdown the webapps
> - shutdown the connector
> This will give requests which were being processed time to complete, and
> new requests will no longer be accepted.
> In addition, capability to pause / resume the connector will be added
> (new JMX operations), which will be useful for cluster node maintenance.
> For example, to cleanly take down a node: pause the connector, wait for
> the requests to complete (and session data to replicate), then do the
> needed maintenance, and finally either unpause the connector or restart
> the server.
I will proceed with the implementation of 2 and 3. For 3, it is likely
that I will add "pause" and "resume" methods on the Connector and
ProtocolHandler.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Three proposals
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> Any and all performance improvements would be greatly appreciated.
>>
>> For those who have not seen it, Sun is touting their "SunONE is
>> better performed / more scalable than Apache 2 + Tomcat" benchmark.
>> While Tomcat and mod_jk[2]'s sole goal is not to scale and perform
>> every bit as well as every other web server / servlet engine
>> alternative and benchmarks are often full of lies, I think it is in
>> everyone's best interest to keep an eye out for opportunities to
>> ensure Tomcat 5 remains competetive in terms of performance and
>> scalability.
>
> Good for them. However, I'd like to point out that mod_jk 2 is not the
> best for throughtput. The HTTP connector is. Performance wise, it
> can't really improve anymore, but I'll try to optimize memory usage to
> get more scalability (I think it's good enough right now, though).
I realize that the extra inter-process hop and marshalling incurred by
mod_jk[2] are bound to cause some reduction in throughput.
I was actually more concerned by the (lower) scalability plateaus they
are showing for Tomcat than the performance per se.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Three proposals
Posted by Jess Holle <je...@ptc.com>.
In general, I agree that general benchmarks are useless and can be
slanted towards any alternative you choose.
Also I agree that Tomcat generally seems to perform quite well and reliably.
--
Jess Holle
Peter Lin wrote:
>
>As usual, these types of comparisons aren't really useful or even desirable. I remember there used to be a benchmark JSR, but it was with drawn. one of these days, a standard set of web and ejb benchmark apps should be created. that way, instead of the usual simple jsp tests, the performance measurements would be more indicative of how a webapp might perform.
>
>from my own experience with coyote connector, it is equal to SunOne, orion, resin, and weblogic. this is based on real applications benchmarked on several servlet containers. Compared to Tomcat 3.2 and older, TC5 has made great strides and remy has worked his butt off. I won't bother pointing out flaws in other servlet containers, since it leads to flame wars. you can google for that information yourself.
>
>peter lin
>
>Remy Maucherat <re...@apache.org> wrote:
>Jess Holle wrote:
>
>
>>Any and all performance improvements would be greatly appreciated.
>>
>>For those who have not seen it, Sun is touting their "SunONE is better
>>performed / more scalable than Apache 2 + Tomcat" benchmark. While
>>Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit
>>as well as every other web server / servlet engine alternative and
>>benchmarks are often full of lies, I think it is in everyone's best
>>interest to keep an eye out for opportunities to ensure Tomcat 5 remains
>>competetive in terms of performance and scalability.
>>
>>
>
>Good for them. However, I'd like to point out that mod_jk 2 is not the
>best for throughtput. The HTTP connector is. Performance wise, it can't
>really improve anymore, but I'll try to optimize memory usage to get
>more scalability (I think it's good enough right now, though).
>
>Rémy
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>---------------------------------
>Do you Yahoo!?
>Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
>
>
Re: [5.0] Three proposals
Posted by Peter Lin <tc...@yahoo.com>.
As usual, these types of comparisons aren't really useful or even desirable. I remember there used to be a benchmark JSR, but it was with drawn. one of these days, a standard set of web and ejb benchmark apps should be created. that way, instead of the usual simple jsp tests, the performance measurements would be more indicative of how a webapp might perform.
from my own experience with coyote connector, it is equal to SunOne, orion, resin, and weblogic. this is based on real applications benchmarked on several servlet containers. Compared to Tomcat 3.2 and older, TC5 has made great strides and remy has worked his butt off. I won't bother pointing out flaws in other servlet containers, since it leads to flame wars. you can google for that information yourself.
peter lin
Remy Maucherat <re...@apache.org> wrote:
Jess Holle wrote:
> Any and all performance improvements would be greatly appreciated.
>
> For those who have not seen it, Sun is touting their "SunONE is better
> performed / more scalable than Apache 2 + Tomcat" benchmark. While
> Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit
> as well as every other web server / servlet engine alternative and
> benchmarks are often full of lies, I think it is in everyone's best
> interest to keep an eye out for opportunities to ensure Tomcat 5 remains
> competetive in terms of performance and scalability.
Good for them. However, I'd like to point out that mod_jk 2 is not the
best for throughtput. The HTTP connector is. Performance wise, it can't
really improve anymore, but I'll try to optimize memory usage to get
more scalability (I think it's good enough right now, though).
R�my
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
Re: [5.0] Three proposals
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> Any and all performance improvements would be greatly appreciated.
>
> For those who have not seen it, Sun is touting their "SunONE is better
> performed / more scalable than Apache 2 + Tomcat" benchmark. While
> Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit
> as well as every other web server / servlet engine alternative and
> benchmarks are often full of lies, I think it is in everyone's best
> interest to keep an eye out for opportunities to ensure Tomcat 5 remains
> competetive in terms of performance and scalability.
Good for them. However, I'd like to point out that mod_jk 2 is not the
best for throughtput. The HTTP connector is. Performance wise, it can't
really improve anymore, but I'll try to optimize memory usage to get
more scalability (I think it's good enough right now, though).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] Three proposals
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Here are some new proposals.
>
> 1) Optimization of the session implementation.
> The session is not a thread safe object. In Tomcat, the session
> implementation is partially thread safe for some reason (this has been
> like that since Tomcat 4.0, AFAIK). As a result, we can remove some
> synchronization. The code should also be simplified (fewer HashMap
> lookups - ex: remove will return the removed object if there was one,
> so removeAttribute should be a lot simpler), and avoid event object
> allocations when it is not useful. As a result of this, setAttribute
> will become much faster.
> In addition to this, I will experiment with fixing bug 26051, and will
> need to add a new endAccess method to the Session interface to do this.
> All this are rather high risk changes, and should not be ported to 4.1.x.
Any and all performance improvements would be greatly appreciated.
For those who have not seen it, Sun is touting their "SunONE is better
performed / more scalable than Apache 2 + Tomcat" benchmark. While
Tomcat and mod_jk[2]'s sole goal is not to scale and perform every bit
as well as every other web server / servlet engine alternative and
benchmarks are often full of lies, I think it is in everyone's best
interest to keep an eye out for opportunities to ensure Tomcat 5 remains
competetive in terms of performance and scalability.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0] Three proposals
Posted by Remy Maucherat <re...@apache.org>.
Here are some new proposals.
1) Optimization of the session implementation.
The session is not a thread safe object. In Tomcat, the session
implementation is partially thread safe for some reason (this has been
like that since Tomcat 4.0, AFAIK). As a result, we can remove some
synchronization. The code should also be simplified (fewer HashMap
lookups - ex: remove will return the removed object if there was one, so
removeAttribute should be a lot simpler), and avoid event object
allocations when it is not useful. As a result of this, setAttribute
will become much faster.
In addition to this, I will experiment with fixing bug 26051, and will
need to add a new endAccess method to the Session interface to do this.
All this are rather high risk changes, and should not be ported to 4.1.x.
2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from
me :-( I plan to use the '#' character instead, which is not useable in
a URI.
3) New connector shutdown. There is a problem with the current Tomcat
shutdown order. It works like this:
- shutdown the connector
- shutdown the webapps (which includes waiting for servlet exec to
end, which doesn't make much sense since the connector and its sockets
are all gone)
This causes trouble in clustering scenarios, where requests which are
currently being process will fail in a non predictible fashion. Shutting
down in reverse order will not fix problems, as the connector will
continue accepting requests (this would help a little, however).
So I propose using the following shutdown routine:
- notify the connector to stop accepting new requests (we can call
this "pausing" the connector)
- shutdown the webapps
- shutdown the connector
This will give requests which were being processed time to complete, and
new requests will no longer be accepted.
In addition, capability to pause / resume the connector will be added
(new JMX operations), which will be useful for cluster node maintenance.
For example, to cleanly take down a node: pause the connector, wait for
the requests to complete (and session data to replicate), then do the
needed maintenance, and finally either unpause the connector or restart
the server.
Comments ?
I will do this after the next stable 5.0.x release (hopefully it will be
5.0.18 :) ), except 1) (where it's centered on one source file, mostly,
so it'll be easy to tag the right revision).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: problem with getParamater in relation to character encoding.
Posted by Stefanos Karasavvidis <st...@msc.gr>.
see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929
there is a nice summary on what you can do (coyote connect attribute
useBodyEncodingForURI)
Stefanos
Deepak Sharma wrote:
> I m not able to display japanese characters in the browser because of the
> problem with getParamater in tomcat which does not autmatically encode
> the request string in the charset set for the page.
>
> I m on the lookout for a patch related to this or ny pointers to solve this
> problem.
> I do not want to use this piece of code as it'll need me to do a lot of code
> change.\
> "decode_str = new String(str.getBytes("8859_1") ,"UTF-8");"
>
> Please help me out with this.
>
> Regards,
> Deepak Sharma.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org