Re: Session replication configuration file question

2013-12-30 Thread Nir A
Hi Daniel,
At last we managed to solve the replication issue. (not exactly a solution
but a workaround) :

the problem was:

The multicast tried to broadcast to local ip written in the hosts file
127.0.1.1
We had to write the actual ip adress in the hosts file

instead :

127.0.1.1 - Tomcat1

we changed to

tomcat1_ip_adress - Tomcat1


and the same on the tomcat 2 machine.

now it works.

thanks for your efforts.




On Sun, Dec 29, 2013 at 8:43 PM, Daniel Mikusa dmik...@gopivotal.comwrote:

 On Dec 29, 2013, at 10:51 AM, Nir A n...@netomedia.com wrote:

  Hi,
 
  If i want to create a cluster of 2 tomcats:
 
  Tomcat1 - ip 111.111.111.111
  Tomcat2 - ip 222.222.222.222
 
 
  Where exactly the in the server.xml i should say that my cluster contains
  both of these ips?

 By default, you don't.  If you'd rather do that, you can though.  See my
 previous email to you regarding StaticMember configuration.

  If you will take alook at my server.xml (which i copy pasted from the
  tutorial) it looks like this:
 
  ?xml version='1.0' encoding='utf-8'?
 
  Server port=8105 shutdown=SHUTDOWN
 
   Listener className=org.apache.catalina.core.AprLifecycleListener
  SSLEngine=on /
 
   Listener className=org.apache.catalina.core.JasperListener /
 
   Listener
  className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
   Listener
  className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
 /
   Listener
  className=org.apache.catalina.core.ThreadLocalLeakPreventionListener /
 
   GlobalNamingResources
 
 Resource name=UserDatabase auth=Container
   type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
 
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
   pathname=conf/tomcat-users.xml /
   /GlobalNamingResources
 
 
   Service name=Catalina
 
 
 Connector port=8080 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=8443 /
 
 Connector port=8109 protocol=AJP/1.3 redirectPort=8443 /
 
 
 Engine name=Catalina defaultHost=localhost
  Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
   Manager className=org.apache.catalina.ha.session.BackupManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true
mapSendOptions=6/
  /Cluster
 
   Realm className=org.apache.catalina.realm.LockOutRealm
 Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
   /Realm
 
   Host name=localhost  appBase=webapps
 unpackWARs=true autoDeploy=true
 
 Valve className=org.apache.catalina.valves.AccessLogValve
  directory=logs
prefix=localhost_access_log. suffix=.txt
pattern=%h %l %u %t quot;%rquot; %s %b /
 
   /Host
 /Engine
   /Service
  /Server
 
  Again, It doesn't make sense to me that this configuration will work
 since
  the ips (111.111.111.111 , and 222.222.222.222) are not in it.

 The Cluster tag adds some default options for you.  See this link for more
 on the defaults.


 http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html#For_the_impatient

 Specifically look at the Membership / tag which defines the multicast
 service.  This is how instances find each other by default.

  Where exactly should i define them?

 Again, see my other note regarding StaticMember configuration.

 Dan

 
  Thanks


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: Compressed SVG support (*.svgz) in Tomcat

2013-12-30 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 12/28/13, 3:20 PM, David Law wrote:
 No Content-Encoding header is sent in the response. And that is
 exactly the problem: DefaultServlet needs to be changed to serve up
 svgz's with Content-Encoding gzip

Okay, so you would then need to use this:

 If you want to serve pre-compressed content then you'll have to
 do some work yourself (unless you are using Tomcat 8). There have
 been a few discussions on the various lists over the past few
 years. For example,
 
 http://markmail.org/message/w2kpjqibrkxmxmup 
 http://markmail.org/thread/h5kyjofpkglpkfks
 
 Tomcat 8.0.4-RC4+ should already support pre-compressed files: 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=54095
 I am aware of the changes made by Philippe Marschall (r1531115) 
 Mark Thomas regarding gzip. This is quite useful but does not
 address my Issue.

It should: your scenario is exactly the one targeted by the patch.

 It could be used (as a workaround) if compressed SVG's had the
 extension .svg.gz

What's wrong with .svgz? Tomcat's out-of-the-box MIME types include
mappings for .svg and .svgz, which appears to be appropriate.

http://www.w3.org/services/svg-server/

I've also read http://kaioa.com/node/45 but the use of
Content-Encoding appears to be a hack: the SVG reader should accept
both uncompressed and gzip-compressed streams. It does not seem
reasonable for Tomcat itself to include this specific hack.

I'm still not sure why Phillipe's solution does not give you what you
need: it adds pre-compressed file-serving capabilities, which is
exactly what you want. You said above that it doesn't meet your needs:
in what was is that solution lacking?

 But they don't: W3C specifies the extension as .svgz We just need
 Tomcat to serve up svgz's with Content-Encoding gzip. Something
 like this: if (contentType.equals(image/svg+xml) 
 path.toLowerCase().endsWith(.svgz)) { 
 response.addHeader(Content-Encoding, gzip); }

See markt's reply for an example filter.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwY1AAAoJEBzwKT+lPKRYqkAP/2xFxRpSsWZaJYGo4YYeaAld
ouRlfZdl8PKGZaDOufXJmsJtCXoQAV/nU40o9PSkF9aYE5v2AKW3c0AXod1PgE09
2ZbDTaPHBcXj24nH74HgsNe3LgROOWy1//lJSrK8HncHe2lQYfpzBPzJrv89DdxN
tKmqeR6s+JILGxWyx1EN95sD7DIQqGJ3XJbIYBzyRVVT7tDCDnV+TNdCxNWBO3qX
Jrmhnrntkl+yCY8b2ETu+18+fBmB+T88kf0Dta74qIAXbYezZom5xYcXit7ITBEA
1GyEgyvGzYbliRDXKiYn1a1LJV+C1vwBpZb86Tt7kkcd6a5H+6kYUjk9hK7QomdJ
v0yXCRKfuqUhagSz3eCOeZiYHyhfPtVDOlduRu3OzGOL+7lirZpcxPn2GxaGdRuW
XAoCHs1Wce+LhWsBOMkX/67ygZ2zpCqVgjZiRetZ5czx0Xyx+/S4mTpY6zN6Ieh6
SqeU/MjWNmzkJWJG45Q6WQhqZQJ508Z5EGi+ACjIv6kp6T08GpIKt4GzLqnQrXiU
Zrwr/saMIu2xxxMh+FnUIPWFLkl3YzvSrpVH9ovasmdR7ZJCbc72s5EyLvw8cjJs
7Sd9faxgT4ZFqeGgEmpV8fA4w47HLwLFFe5HD3D19DKpxs7PBiIJVIWd0n14uPKu
Kh3EgQVgNH8VxmvOu4fH
=WTmg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how http connector backlog attribute works?

2013-12-30 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

侯树成,

On 12/27/13, 4:24 AM, 侯树成 wrote:
 Yes, this must use BIO mode, because the NIO maxConnections=1
 in default, it won't block the LimitLatch. In my test case,(use
 JMeter, thread number is 5), 2 requests will refused soon(just
 1s-2s later), then another 3 requests will served correctly.In
 source code, I find the backlog attribute will send to ServerSocket
 constructor, So, the backlog attribute is worked inside of JDK, not
 in Tomcat?

The backlog is technically handled in the OS kernel/TCP stack. This
page is Linux-specific, but implements a BSD standard.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwaKaAAoJEBzwKT+lPKRYuwQP/2loOTXAeSXg15ptpUPOcRH6
8bKk/zf5bxuUCClrYSEaxiDT+RpD8yINynGZRrR+c+wVYuOBoKSSoFwpoFFgovrk
8KvNZHC6GC3/qDwDGs4t69cuiN/KBjLiSygJI/arxIoxDVbc1jKUzUsvGpBYC4Hm
FdiTddvyslQy+xR8Klw1Ak4ccTYKcZSPXDXZ/s9z8ELYlswAWq7LGRSJqdJI2BNG
Ja92dLSEQ4NTHSxfEXeWusrf51tJFqXLq1kjfALGlXdL9FC05Phc+PCXPBAbcQsW
acaUMy6ry8aqtZ3rdAdIHFSjxqHtxr5Ffehe8VmjcGXYqWBa7ez6q8zd+Ku9BDBB
NCna9X8NFRZT4J8/uJxaXiAiUvxUVEBG4uwRTMx8UebKWQNm8v25tKMHl0z0T/Jt
/YsqoTFjQ8/KniDrKaqTcn9BrQLiiTFUTI26t9e7S0V5xF2r8Pk98mkf0mCDl2+7
D7GCGAOwkOhyMFc9fQ2PGKzlKb3EjCas5+7ICRp6qFoa2NLvRls64E6iLlcAEcf1
lC86qqJbHVhE1KNAmSS0pGo/b7zTi54LkssmPzg7Z/3iJ0ugL0KbamPMfetr1HYP
9yINYpVlJK55zKgsvOz63UnUnciDJGxf9IRrgcGNZSaupPKbtj15ewqNLBr30X4F
sRcDOHUX8RdojgBljhAX
=ZYMg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Java to JavaScript RMI framework available.

2013-12-30 Thread Igor Urisman
Folks,

I needed to write this for something I am working on and thought there
might be a wider audience for it.
Tomcat 8 supports standard compliant Websockets, which provide convenient
asynchronous full-duplex
server to client data transport. The framework I am offering builds on top
of that a feature rich remote
method invocation paradigm.  Please check it out.

https://github.com/iurisman/FERMI
Apache 2.0 license.

Happy coding.
Igor.


the acceptCount attribute not work like it's configuration

2013-12-30 Thread 侯树成
Hi,
Today, I find the acceptCount  of connector is not work like it's config.
You can try it like this:
Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=2 maxThreads=1
minSpareThreads=1/

use LR or JMeter make more requests( 10) .  You will find that 5 requests
will served correctly, others will be refused.

When the acceptCount=3
   Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=3 maxThreads=1
minSpareThreads=1/

 You will find that 7 requests will served correctly, others will be
refused.


When the acceptCount=4
   Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 acceptCount=4 maxThreads=1
minSpareThreads=1/

 You will find that 9 requests will served correctly, others will be
refused.

Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right?

why the acceptCount is not work like it's configuration?

Could you help me? Thank you.


Re: Compressed SVG support (*.svgz) in Tomcat

2013-12-30 Thread David Law

Chris,

these are 2 completely different issues.

svgz's should be served with the correct encoding (gzip)
as required by the W3C SVG standard.  ALWAYS.
http://www.w3.org/TR/SVG11/conform.html#ConformingSVGServers
That means, files with the extension .svgz will be served,
as they are, with the Content-Encoding header gzip.
This is performance-neutral.

The Patch is something completely different:
it serves a file with a particular extension, say *.XXX,
from *.XXX.gz, if present.  SOMETIMES (depending on the Servlet 
gzip-parameter).

This will add a certain overhead, server-side, for EVERY FILE served.
(because if present implies a resources lookup)

svgz's have the extension .svgz, not .svg.gz or .svgz.gz
or anything else for that matter, so The Patch will not
have any effect, and should not, for that matter.

All the best,
DaveLaw

On 30/12/2013 16:12, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 12/28/13, 3:20 PM, David Law wrote:

No Content-Encoding header is sent in the response. And that is
exactly the problem: DefaultServlet needs to be changed to serve up
svgz's with Content-Encoding gzip

Okay, so you would then need to use this:


If you want to serve pre-compressed content then you'll have to
do some work yourself (unless you are using Tomcat 8). There have
been a few discussions on the various lists over the past few
years. For example,

http://markmail.org/message/w2kpjqibrkxmxmup
http://markmail.org/thread/h5kyjofpkglpkfks

Tomcat 8.0.4-RC4+ should already support pre-compressed files:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54095

I am aware of the changes made by Philippe Marschall (r1531115) 
Mark Thomas regarding gzip. This is quite useful but does not
address my Issue.

It should: your scenario is exactly the one targeted by the patch.


It could be used (as a workaround) if compressed SVG's had the
extension .svg.gz

What's wrong with .svgz? Tomcat's out-of-the-box MIME types include
mappings for .svg and .svgz, which appears to be appropriate.

http://www.w3.org/services/svg-server/

I've also read http://kaioa.com/node/45 but the use of
Content-Encoding appears to be a hack: the SVG reader should accept
both uncompressed and gzip-compressed streams. It does not seem
reasonable for Tomcat itself to include this specific hack.

I'm still not sure why Phillipe's solution does not give you what you
need: it adds pre-compressed file-serving capabilities, which is
exactly what you want. You said above that it doesn't meet your needs:
in what was is that solution lacking?


But they don't: W3C specifies the extension as .svgz We just need
Tomcat to serve up svgz's with Content-Encoding gzip. Something
like this: if (contentType.equals(image/svg+xml) 
path.toLowerCase().endsWith(.svgz)) {
response.addHeader(Content-Encoding, gzip); }

See markt's reply for an example filter.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwY1AAAoJEBzwKT+lPKRYqkAP/2xFxRpSsWZaJYGo4YYeaAld
ouRlfZdl8PKGZaDOufXJmsJtCXoQAV/nU40o9PSkF9aYE5v2AKW3c0AXod1PgE09
2ZbDTaPHBcXj24nH74HgsNe3LgROOWy1//lJSrK8HncHe2lQYfpzBPzJrv89DdxN
tKmqeR6s+JILGxWyx1EN95sD7DIQqGJ3XJbIYBzyRVVT7tDCDnV+TNdCxNWBO3qX
Jrmhnrntkl+yCY8b2ETu+18+fBmB+T88kf0Dta74qIAXbYezZom5xYcXit7ITBEA
1GyEgyvGzYbliRDXKiYn1a1LJV+C1vwBpZb86Tt7kkcd6a5H+6kYUjk9hK7QomdJ
v0yXCRKfuqUhagSz3eCOeZiYHyhfPtVDOlduRu3OzGOL+7lirZpcxPn2GxaGdRuW
XAoCHs1Wce+LhWsBOMkX/67ygZ2zpCqVgjZiRetZ5czx0Xyx+/S4mTpY6zN6Ieh6
SqeU/MjWNmzkJWJG45Q6WQhqZQJ508Z5EGi+ACjIv6kp6T08GpIKt4GzLqnQrXiU
Zrwr/saMIu2xxxMh+FnUIPWFLkl3YzvSrpVH9ovasmdR7ZJCbc72s5EyLvw8cjJs
7Sd9faxgT4ZFqeGgEmpV8fA4w47HLwLFFe5HD3D19DKpxs7PBiIJVIWd0n14uPKu
Kh3EgQVgNH8VxmvOu4fH
=WTmg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



doe response auto commit when browser abort or close?

2013-12-30 Thread 侯树成
Hi, I got an Exception like this:

java.lang.IllegalStateException: Cannot call sendError() after the response
has been committed


I got it in following steps:
1. Deploy a web app.
2. request the app in browser, refresh the page when it not response
fully(or close it when the page not response correctly)
3. get the exception


the exception was throw in blow code:

class OutputBuffer
 public void realWriteBytes(byte buf[], int off, int cnt) {
 .
coyoteResponse.doWrte(outputChunk);   //it will throw
java.io.IOException: An established connection was aborted
  //by the software in your host
machine
} catch (IOException e) {
// An IOException on a write is almost always due to
// the remote client aborting the request.  Wrap this
// so that it can be handled better by the error dispatcher.
throw new ClientAbortException(e);  // it will handled by
outter code.But now the commit equals true when sendError method execute,
so
   //IllegalStateException will throw.
}
}

Does the response will set commit = true when the client close or abort?
In source code, I just find the flush method or close method will set
commit = true, others was correct request/response lifecycle.

Thanks in advance.