date:20131229


Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 12/28/13, 12:06 PM, David Law wrote:
Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly. 
The response should have a Content-Encoding header, value 'gzip'.


Any chance of getting this at long last? (a change to
org.apache.catalina.servlets.DefaultServlet, I presume)

Version: 7.0.47


What type of data do you have on the disk? What content-type? What
content-type and content-encoding are sent to the browser?

Tomcat's DefaultServlet should serve any file using gzip (with an
appropriate content-encoding) that matches the configured mime types
and isn't smaller than a certain size. All of these can be configured
with the compression, compressableMimeType, and compressionMinSize
attributes on your Connector. Note that use of sendFile precludes
the use of gzip compression, so if you are using sendFile you aren't
going to get that kind of encoding.

- From a stock Tomcat install, to get .svg files served using
content-encoding:gzip, you'd need to modify your Connector to have
the following attributes:

   compression=on
   compressableMimeType=, image/svg+xml
   compressionMinSize=[big enough to exceed your file size


I believe that this should be instead : [small enough to *not* exceed you file 
size].
No ?


   sendFile=false (if appropriate)




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

Re: Tomcat work directory is not creating a sessions.ser file

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

 Hi,
 
 We had problems regarding sessions replication.
 We contact you before and after you examined our logs you actually told us
 that session replication is indeed talking place although we didn't have
 session replication.
 
 Now, after further investigation we think we are on the problem source:
 
 
 If we create a session in one of our tomcats, the file sessions.ser is
 not being created at all.
 
 1) what could be the cause for that?

1.) You have this feature disabled.

  
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts

2.) You're not shutting down Tomcat.  This file is only created to persist 
sessions over restart.

See pathname...

  
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Standard_Implementation

3.) You're using a clustered manager (DeltaManager or BackupManager), which 
would not save sessions to disk.

 2) Could that bug be the primary reason why we get no session replication?

I do not believe the session serialization file is related to session 
replication (i.e. clustering) in any way.

Dan


 
 thanks!


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

Re: tomcat - How to forward request to some webapp while using port 80 without virtual host, without apache

Peter wrote:

I am happy that you guys sent reply to me, but anyone here can create
configuration file for me for example which I had mentioned in beginning of
post, then I can understand better, its my weakness but true.

Peter, you should decide what you want, and whether the way in which to do it, is more
important for you than the goal that you want to reach, or vice-versa.

From what I understand, the final result that you want to achieve is that
1) there is only one Tomcat server instance
2) when a client calls up http://client1.company.com/, this ends up being served by the
application /client1
3) when a client calls up http://client2.company.com/, this ends up being served by the
application /client2

The easiest and most natural way to do this, is by using Virtual Hosts, and have
client1 and client2 being in fact the ROOT webapps of each of these virtual hosts.

Like this :

DNS :
a.b.c.d client1.company.com
a.b.c.d client2.company.com
(same IP for both)

Tomcat connectors : listen on the IP address a.b.c.d

Tomcat virtual hosts :
First, the default host (it is already there, nothing to change)
Host name=localhost appBase=(tomcat_dir)/webapps ..
.. here you host Tomcat's standard webapps (just leave them where they are)
/Host

Then you add the following 2 Hosts :

Host name=client1.company.com appBase=/dir1/webapps ...
... here you host the client1 webapp, renamed to ROOT, as in
/dir1/webapps/ROOT/..
/Host

Host name=client2.company.com appBase=/dir2/webapps ...
... here you host the client2 webapp, renamed to ROOT, as in
/dir2/webapps/ROOT/..
/Host

This is a still single Tomcat. The fact of using virtual hosts does not mean that there
are more than 1 Tomcat. It is the same single Tomcat serving all 3 above virtual hosts.

It just changes its personality depending on how the client gets to it (by
the name).

But, in the subject of your message, you say that you do not want virtual hosts.

That's a pity, because any other way of doing what you seem to want to do, is a lot more
complicated, and a lot more complicated still to get right in all cases.

So, once again, *why* do you not want virtual hosts ?
If you do not really care, then I suggest that you start a new message thread, with a
different title where you do not exclude virtual hosts from the start, and just explain
what you want to achieve in the end, without excluding any particular solution right away.

For the rest, apart from the on-line Tomcat documentation, there are also books and
articles available : http://tomcat.apache.org/resources.html.
If what you want is to have someone spoon feed a complete configuration to you, that
will work in your case without any effort on your part, then you should consider hiring a
paid consultant.

There is also a list here : http://wiki.apache.org/tomcat/SupportAndTraining

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

Re: Non-Blocking IO Write Issue

On Dec 23, 2013, at 7:55 PM, David Bullock david.bull...@machaira.com.au 
wrote:

 On 24 December 2013 07:58, Daniel Mikusa dmik...@gopivotal.com wrote:
 On Dec 19, 2013, at 8:08 PM, David Bullock david.bull...@machaira.com.au 
 wrote:
 
 On 20 December 2013 04:10, Daniel Mikusa dmik...@gopivotal.com wrote:
 
 Unfortunately, once this problem starts to occur onWritePossible doesn't get 
 called back.
 
 When I take a thread dump of the code, it just shows all of the threads 
 doing nothing.
 
 Increasing timeout doesn't seem to help.  Failures still occur within the 
 same timeframe (i.e. same number requests to the server).  The only affect 
 is to create a delay between when requests stop being processed and the 
 stack trace shows up.
 
 What happens if you instead pass the ServletOutputStream to the 
 DataStreamWriteListener's constructor?
 
 Unfortunately nothing.  I still see the issue.
 
 OK, new theory.  At some point, something happens in your onWritePossible
 handler which throws an unchecked exception and crashes the Tomcat thread
 which is responsible for keeping track of which async servlets are
 still wanting to write data and doing appropriate cleanup of the NIO 
 selectors/keys.

When onWritePossible is called by Tomcat, it's wrapped in a 
try..catch..finally, which catches Throwable.  If it catches something, the 
write listener's onError method should get called with the exception.  That's 
not happening in my unit test, so it doesn't seem like an exception is being 
raised in onWritePossible.

See around line 369.

   
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=markup

 My money would have been on calling getOutputStream() on the response a 
 second time
 (it throws java.lang.IllegalStateException, which is unchecked), but
 you say you got rid of that.  

As far as I can tell, you should be able to call getOutputStream() as many 
times as you want.  According to the javadoc, it only throws 
IllegalStateException if you've called getWriter() and then call 
getOutputStream().

  
http://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletResponse.html#getOutputStream()

 To eliminate other unchecked candidates, make your
 onWritePossible() catch java.lang.Throwable and emit appropriate log messages
 if it catches anything (or more usefully, point a debugger at the catch 
 clause).

Tried this.  Unfortunately, it does not catch anything.

 If that doesn't yield success, then I would like to see 2 thread dumps
 - once when
 onWritePossible() has been called (maybe put in a Thread.sleep(5000) so you
 have time to tickle the JVM),

Here's a thread dump from the unit test, which I've paused in the debugger 
during the first call to the onWritePossible method.

2013-12-29 09:07:04
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):

http-nio-127.0.0.1-auto-1-exec-1 daemon prio=5 tid=0x7fde4b888000 
nid=0x8403 at breakpoint[0x0001965b4000]
   java.lang.Thread.State: RUNNABLE
at 
org.apache.catalina.nonblocking.TestWriteListener$DataStreamingServlet$DataStreamWriteListener.onWritePossible(TestWriteListener.java:114)
at org.apache.coyote.Response.onWritePossible(Response.java:658)
at 
org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:369)
at 
org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1618)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:631)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1576)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1534)
- locked 0x000165068000 (a org.apache.tomcat.util.net.NioChannel)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

http-nio-127.0.0.1-auto-1-Acceptor-0 daemon prio=5 tid=0x7fde4f07e000 
nid=0x8203 runnable [0x000197303000]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:241)
- locked 0x000165018110 (a java.lang.Object)
at 
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:693)
at java.lang.Thread.run(Thread.java:744)

http-nio-127.0.0.1-auto-1-ClientPoller-1 daemon prio=5 tid=0x7fde4b89f800 
nid=0x8003 runnable [0x000197124000]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:200)

Session replication does not work - Continued

2013-12-29 Thread Nir A

Hi,
So we have 3 tomcats in our cluster and we are failing to make them
replicate our sessions still.

Our IT guy said it might has something to do with the machines of the
tomcats.

He said that since the machines the tomcats in the cluster are installed at
are Virtual machines there might be a problem on the multicast of the
replication messages.

1) Is it possible that our IT guy is right? (We love you Leon)
2) Is there any alternative to multicast the session data between the
tomcats?


Thanks!

Session replication configuration file question

2013-12-29 Thread Nir A

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?
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.
Where exactly should i define them?

Thanks

Re: Non-Blocking IO Write Issue

2013-12-29 Thread David Bullock

Well, the states of those threads look normal enough. Definitely not
a resource starvation issue (which is what it 'feels' like). I guess
some values are getting lost somewhere.

Just looking at the stacktrace for the onWritePossible() example
though ... I'm not able to trace the same execution path through the
version of the Tomcat trunk, except by going back some weeks/months.
For example, with:

... well, the AbstractHttp11Processor.asyncDispatch() method seems to
have been refactored out in May, earlier this year:

http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?r1=1478576r2=1478714diff_format=h

Reading the source code and the repository, it seems there has been a
*lot* of activity around this async stuff in the codebase, and you may
well get different test results with a more modern version of the
trunk.

cheers,
David.
David Bullock
Machaira Enterprises Pty Ltd

PO Box 31
Canowindra NSW 2804

02 6344 1100
http://machaira.com.au/

On 30 December 2013 01:21, Daniel Mikusa dmik...@gopivotal.com wrote:
On Dec 23, 2013, at 7:55 PM, David Bullock david.bull...@machaira.com.au
wrote:

On 24 December 2013 07:58, Daniel Mikusa dmik...@gopivotal.com wrote:
On Dec 19, 2013, at 8:08 PM, David Bullock david.bull...@machaira.com.au
wrote:

On 20 December 2013 04:10, Daniel Mikusa dmik...@gopivotal.com wrote:

Unfortunately, once this problem starts to occur onWritePossible doesn't
get called back.

When I take a thread dump of the code, it just shows all of the threads
doing nothing.

Increasing timeout doesn't seem to help. Failures still occur within the
same timeframe (i.e. same number requests to the server). The only affect
is to create a delay between when requests stop being processed and the
stack trace shows up.

What happens if you instead pass the ServletOutputStream to the
DataStreamWriteListener's constructor?

Unfortunately nothing. I still see the issue.

OK, new theory. At some point, something happens in your onWritePossible
handler which throws an unchecked exception and crashes the Tomcat thread
which is responsible for keeping track of which async servlets are
still wanting to write data and doing appropriate cleanup of the NIO
selectors/keys.

When onWritePossible is called by Tomcat, it's wrapped in a
try..catch..finally, which catches Throwable. If it catches something, the
write listener's onError method should get called with the exception. That's
not happening in my unit test, so it doesn't seem like an exception is being
raised in onWritePossible.

See around line 369.

http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=markup

My money would have been on calling getOutputStream() on the response a
second time
(it throws java.lang.IllegalStateException, which is unchecked), but
you say you got rid of that.

As far as I can tell, you should be able to call getOutputStream() as many
times as you want. According to the javadoc, it only throws
IllegalStateException if you've called getWriter() and then call
getOutputStream().

http://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletResponse.html#getOutputStream()

To eliminate other unchecked candidates, make your
onWritePossible() catch java.lang.Throwable and emit appropriate log messages
if it catches anything (or more usefully, point a debugger at the catch
clause).

Tried this. Unfortunately, it does not catch anything.

If that doesn't yield success, then I would like to see 2 thread dumps
- once when
onWritePossible() has been called (maybe put in a Thread.sleep(5000) so you
have time to tickle the JVM),

Here's a thread dump from the unit test, which I've paused in the debugger
during the first call to the onWritePossible method.

2013-12-29 09:07:04
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):

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


Mark,

many, many thanks for your prompt action. :-)

I will add my thoughts to your JIRA 
https://java.net/jira/browse/SERVLET_SPEC-86.


I guess the matter is now out of our hands
 we have to hope the Servlet guys @ java.net
are open to our proposal.  I hope it won't take years,
as I have a feeling the adoption of SVG is threatened
by the lack of support for svgz's: there are an awful
lot of people trawling the internet for an answer.

Would it be too much trouble to detail
how such a Filter-Definition might look?
(I really am quite new to all this, being
 more at home with a mainframe)

There is another workaround: we got a change 
http://code.google.com/p/primefaces/issues/detail?id=4264 to

PrimeFaces through in 2012 which was released
with 3.5  retrospectively 3.4.3, so it is possible to
write a backing-bean to serve svgz's via p:graphicImage.

Thanks again,
DaveLaw

On 29/12/2013 10:06, Mark Thomas wrote:

On 28/12/2013 21:36, David Law wrote:

I just tried this in DefaultServlet:

if (contentType.equals(image/svg+xml)
  path.toLowerCase().endsWith(.svgz)) {
 response.addHeader(Content-Encoding, gzip);
}

Quick  dirty, but Works fine as proof-of-concept.
We just need a DefaultServlet expert to do the slow  clean stuff.

I'd suggest simply using a filter mapped to *.svgz for now.


I believe a generic solution to be best though, long-term. Something like:

That would be my preference but would require a change from the Servlet
EG. I'm not sure if adding a element to mime-mapping or adding a new
encoding-mapping element is the best solution. I created
https://java.net/jira/browse/SERVLET_SPEC-86 - feel free to add comments.

Mark


-
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


Hi Jan,

yes, that's the problem  plain-text SVG's are so bloated.

Opera does a stateful inspection of the stream to see
if its compressed or not, but the Spec states they must
be marked as gzip-Encoded in the Response Header, so we
can't really fault Firefox  co for adhering to that Spec.

The Internet Forums are full of entries from people
looking for a solution, so I hopethe JIRA  
https://java.net/jira/browse/SERVLET_SPEC-86  Mark created
will meet with approval.

All the best,
DaveLaw

On 29/12/2013 11:18, Jan Tosovsky wrote:

On 2013-12-28 David Law wrote:

On 28/12/2013 19:34, Christopher Schultz wrote:


What type of data do you have on the disk?

Its all standard stuff.  As specified by W3C, compressed SVG's
are just SVG's (which are just XML) compressed with gzip, with
a Mime-Type of image/svg+xml, and extension .svgz

Btw, I've stopped using compressed SVG variant for web recently as
1. stored on local disk couldn't be displayed in some browsers (works in 
Chrome, but not in FF or IE) - my files were intended for downloading by users 
hence this was a serious limitation.
2. all my web content is transferred to the client gzipped anyway so there is 
no gain in the 'content length'.
3. no additional settings was required

Jan



-
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


Hi André,

no.  I think Chris was semantically correct with
[big enough to exceed your file size]

Unfortunately, his answer had nothing to do with my posting.

Mark Thomas hit the nail on the head though:
http://tomcat.markmail.org/message/zptxhevgzkpr7if2

All the best,
DaveLaw

On 29/12/2013 14:10, André Warnier wrote:

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 12/28/13, 12:06 PM, David Law wrote:
Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly. 
The response should have a Content-Encoding header, value 'gzip'.


Any chance of getting this at long last? (a change to
org.apache.catalina.servlets.DefaultServlet, I presume)

Version: 7.0.47


What type of data do you have on the disk? What content-type? What
content-type and content-encoding are sent to the browser?

Tomcat's DefaultServlet should serve any file using gzip (with an
appropriate content-encoding) that matches the configured mime types
and isn't smaller than a certain size. All of these can be configured
with the compression, compressableMimeType, and compressionMinSize
attributes on your Connector. Note that use of sendFile precludes
the use of gzip compression, so if you are using sendFile you aren't
going to get that kind of encoding.

- From a stock Tomcat install, to get .svg files served using
content-encoding:gzip, you'd need to modify your Connector to have
the following attributes:

   compression=on
   compressableMimeType=, image/svg+xml
   compressionMinSize=[big enough to exceed your file size


I believe that this should be instead : [small enough to *not* exceed 
you file size].

No ?


   sendFile=false (if appropriate)




-
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

Re: Session replication does not work - Continued

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

 Hi,
 So we have 3 tomcats in our cluster and we are failing to make them
 replicate our sessions still.
 
 Our IT guy said it might has something to do with the machines of the
 tomcats.
 
 He said that since the machines the tomcats in the cluster are installed at
 are Virtual machines there might be a problem on the multicast of the
 replication messages.
 
 1) Is it possible that our IT guy is right? (We love you Leon)

By default, clustering support uses multicast to locate other Tomcat instances. 
 If multicast does not work or is disabled on your instances won't be able to 
locate each other.

Multicast is only used for locating other nodes, it is not used for the 
transmission of session data.  TCP is used for that.

 2) Is there any alternative to multicast the session data between the
 tomcats?

Yes.  See static members configuration.

  
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Static_Membership
  
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-interceptor.html#Nested_element_StaticMember_Attributes

Dan

 
 
 Thanks!


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

Re: Session replication configuration file question

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: Non-Blocking IO Write Issue

On Dec 29, 2013, at 11:45 AM, David Bullock david.bull...@machaira.com.au
wrote:

Well, the states of those threads look normal enough. Definitely not
a resource starvation issue (which is what it 'feels' like). I guess
some values are getting lost somewhere.

http-nio-127.0.0.1-auto-1-exec-1 daemon prio=5
tid=0x7fde4b888000 nid=0x8403 at breakpoint[0x0001965b4000]
java.lang.Thread.State: RUNNABLE
at
org.apache.catalina.nonblocking.TestWriteListener$DataStreamingServlet$DataStreamWriteListener.onWritePossible(TestWriteListener.java:114)
at org.apache.coyote.Response.onWritePossible(Response.java:658)
at
org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:369)
at
org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1618)
... well, the AbstractHttp11Processor.asyncDispatch() method seems to
have been refactored out in May, earlier this year:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?r1=1478576r2=1478714diff_format=h

I would agree that there have been lots of updates, but I am running that
latest update from svn.

$ svn update
At revision 1554057.

Just to make sure Eclipse wasn't doing something weird. I did a clean on the
project and watched it rebuild everything. Looking at the stack trace, I'm
seeing line numbers that correspond to the correct line numbers when I view the
subversion repository in my browser, so I believe it's running with the latest
code. Also I'm able to trace through the code by the file / line number
reported in the stack trace.

Thanks for the suggestions, but at this point I'm reasonably confident I
haven't missed something simple so I've gone ahead and created a bug report.

https://issues.apache.org/bugzilla/show_bug.cgi?id=55939

Dan

cheers,
David.
David Bullock
Machaira Enterprises Pty Ltd

PO Box 31
Canowindra NSW 2804

02 6344 1100
http://machaira.com.au/

On 30 December 2013 01:21, Daniel Mikusa dmik...@gopivotal.com wrote:
On Dec 23, 2013, at 7:55 PM, David Bullock david.bull...@machaira.com.au
wrote:

On 24 December 2013 07:58, Daniel Mikusa dmik...@gopivotal.com wrote:
On Dec 19, 2013, at 8:08 PM, David Bullock david.bull...@machaira.com.au
wrote:

On 20 December 2013 04:10, Daniel Mikusa dmik...@gopivotal.com wrote:

Unfortunately, once this problem starts to occur onWritePossible doesn't
get called back.

When I take a thread dump of the code, it just shows all of the threads
doing nothing.

What happens if you instead pass the ServletOutputStream to the
DataStreamWriteListener's constructor?

Unfortunately nothing. I still see the issue.

When onWritePossible is called by Tomcat, it's wrapped in a
try..catch..finally, which catches Throwable. If it catches something, the
write listener's onError method should get called with the exception.
That's not happening in my unit test, so it doesn't seem like an exception
is being raised in onWritePossible.

See around line 369.

http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=markup

My money would have been on calling getOutputStream() on the response a
second time
(it throws java.lang.IllegalStateException, which is unchecked), but
you say you got rid of that.

http://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletResponse.html#getOutputStream()

To eliminate other unchecked candidates, make your
onWritePossible() catch java.lang.Throwable and emit appropriate log
messages
if it catches anything (or more usefully, point a debugger at the catch
clause).

Tried this.

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

2013-12-29 Thread Mark Thomas

On 29/12/2013 17:17, David Law wrote:
 Mark,
 
 many, many thanks for your prompt action. :-)
 
 I will add my thoughts to your JIRA
 https://java.net/jira/browse/SERVLET_SPEC-86.
 
 I guess the matter is now out of our hands
  we have to hope the Servlet guys @ java.net
 are open to our proposal.  I hope it won't take years,
 as I have a feeling the adoption of SVG is threatened
 by the lack of support for svgz's: there are an awful
 lot of people trawling the internet for an answer.
 
 Would it be too much trouble to detail
 how such a Filter-Definition might look?
 (I really am quite new to all this, being
  more at home with a mainframe)

A quick, dirty and totally untested Filter implementation:
http://people.apache.org/~markt/dev/SvgzFilter.java

Handling the Accept-Encoding header is left as an exercise for the reader.

Mark


 
 There is another workaround: we got a change
 http://code.google.com/p/primefaces/issues/detail?id=4264 to
 PrimeFaces through in 2012 which was released
 with 3.5  retrospectively 3.4.3, so it is possible to
 write a backing-bean to serve svgz's via p:graphicImage.
 
 Thanks again,
 DaveLaw
 
 On 29/12/2013 10:06, Mark Thomas wrote:
 On 28/12/2013 21:36, David Law wrote:
 I just tried this in DefaultServlet:

 if (contentType.equals(image/svg+xml)
   path.toLowerCase().endsWith(.svgz)) {
  response.addHeader(Content-Encoding, gzip);
 }

 Quick  dirty, but Works fine as proof-of-concept.
 We just need a DefaultServlet expert to do the slow  clean stuff.
 I'd suggest simply using a filter mapped to *.svgz for now.

 I believe a generic solution to be best though, long-term. Something
 like:
 That would be my preference but would require a change from the Servlet
 EG. I'm not sure if adding a element to mime-mapping or adding a new
 encoding-mapping element is the best solution. I created
 https://java.net/jira/browse/SERVLET_SPEC-86 - feel free to add comments.

 Mark


 -
 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

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


David Law wrote:

Hi André,

no.  I think Chris was semantically correct with
[big enough to exceed your file size]

Unfortunately, his answer had nothing to do with my posting.

Mark Thomas hit the nail on the head though:
http://tomcat.markmail.org/message/zptxhevgzkpr7if2


You are right, that was hasty of me.
Chris was in fact talking about an alternative : having the files stored /not/ compressed, 
and let Tomcat do the compression.
And I mixed it all up further, thinking of Tomcat only compressing the non-compressed 
files (supposedly larger), and leaving the compressed ones (supposedly smaller) alone.

Neither of which matched your request.



-
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

Mark Thomas wrote:

On 28/12/2013 21:36, David Law wrote:

I just tried this in DefaultServlet:

if (contentType.equals(image/svg+xml)
path.toLowerCase().endsWith(.svgz)) {
response.addHeader(Content-Encoding, gzip);
}

Quick dirty, but Works fine as proof-of-concept.
We just need a DefaultServlet expert to do the slow clean stuff.

I'd suggest simply using a filter mapped to *.svgz for now.

I believe a generic solution to be best though, long-term. Something like:

That would be my preference but would require a change from the Servlet
EG. I'm not sure if adding a element to mime-mapping or adding a new
encoding-mapping element is the best solution. I created
https://java.net/jira/browse/SERVLET_SPEC-86 - feel free to add comments.

As a comment, I would like to add that the adding of a Content-Encoding header for
certain data files served by Tomcat may be interesting for more types than just *.svgz files.
For example, in document-management or archive applications, it is interesting to store
various types of documents on the server in an already-compressed format and serve them
that way, yet have the client receive the information necessary to automatically
uncompress the response content to handle the original format correctly, without having to
use a specific servlet filter or document-retrieval servlet to do so.
The discussion about .svgz is equally applicable to all kinds of *.xxx.gz files for
instance, where xxx may be PDF, MS-Office, plain text or whatever could be stored
pre-compressed on the server. (Applications of the store once, retrieve many times model).

As another side-comment, there seems to exist an ambiguity/error in the following document
: http://www.w3.org/TR/SVGTiny12/mimereg.html

In section Security considerations, it says :

quote

SVG documents may be transmitted in compressed form using gzip compression. For systems
which employ MIME-like mechanisms, such as HTTP, this is indicated by the
*Content-Transfer-Encoding header*; for systems which do not, ...

unquote
(emphasis mine)

but the HTTP specification in RFC 2616 does not have a
Content-Transfer-Encoding header.
It has Content-Encoding and Transfer-Encoding, as two distinct headers with distinct
meanings.

-
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