Multiple instances of Tomcat

[Arghya Das]

Hi all,

I am using JSP as the language and Tomcat 7 as the Server to deploy Web
applications and Using ECLIPSE as the IDE to build the apps on Windows 7
platform..

I have installed Tomcat as a service in Windows and also linked the Tomcat
server with Eclipse.
but the tomcat is behaving in two different ways.
when i try to run the webapp by starting tomcat through Eclipse it behaves
like a standalone instance.
and when i try to start it through windows service it behaves like a
different instance.

Like when i am trying to place a database config, file in Tomcat directory
and call it in a servlet file by using "catalina.base"  running Tomcat
through Eclipse the changes don't take effect.

while when i manually build the war file and upload and run Tomcat as a
windows service it works fine.

Please help.

regards,
Arghya

Re: Session replication will never happen after disabling session persistence across Tomcat restarts

[sanigo]

Yes, I think if uncommented the

 

The ClustedManage could be disabled even if  is defined.

在 16/4/25 下午12:57, Keiichi Fujino 写道:

2016-04-23 15:29 GMT+09:00 sanigo :


Hi!
I have tested quite a few times to confirm that session replication
will not happen after uncommenting  in
conf/context.xml.
If the line is commented out, the session replication will work
happily.


Is there a warning message to your log files?
such as [Manager [xxx] does not implement ClusterManager, addition to
cluster has been aborted.]

if you have uncommented  in conf/context.xml,
All of the Web applications on your Tomcat use the StandardManager as a
session manager.
The StandardManager cannot replicate session.
If you want to replicate session, you have to use
ClusteManager(DeltaManager/BackupManager) as a session manager.
Usually defines a cluster manager template in the  / ,
and then it is cloned by distributable web application.





The versions I have tested are 7.0.68 and 7.0.69.
Any ideas?
san...@gmail.com

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

--
Keiichi.Fujino







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

Re: Tomcat 8.0.28 and above

[bhanu lakkala]

Hi Chris,
Thanks for the response.
I had been using spring 4.0.9 even before I switched to tomcat 8 and I am
continuing to use the same now.

I have tried to configure the Resource a couple of different ways:
1st way: In the context.xml file as below:


2nd Way:
configured a global datasource and a resource link as shown below:
in the context.xml file:


in the server.xml file:




  


The spring config looks like: I have tried both the jee and the bean way of
configuring it..with the same results.







I am also attaching the log file to this email. Please let me know if any
other information could help.
I really appreciate you taking the time to look into this.

Thank you,
Bhanu Lakkala


On Tue, Apr 26, 2016 at 4:04 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Bhanu,
>
> On 4/22/16 9:46 AM, bhanu lakkala wrote:
> > I have been working on an issue for the past few days and wanted to check
> > with you guys if you have any suggestions on fixing this issue.
> > My current technology stack is: windows 7, java 7/8, tomcat 8, axis2
> 1.6.3.
> > I have an axis2 based web service that is very basic and it just connects
> > to a database and reads some info and spits out the info it read.
> > I have setup a JNDI resource for the datasource.  In the service's init
> > class's startup method, I am attempting to load the spring's
> > ApplicationContext and thereby load the JNDI resource.
> > All of this used to work well with the combination of java 7, tomcat 7.x
> > axis2 1.6.3.
> > Recently due to a need to upgrade to newer version of tomcat, I upgraded
> to
> > tomcat 8. this resulted in "Name not found" exception.
>
> I don't believe anything significant changed with Tomcat's handling of
> JNDI DataSources. Are you sure you upgraded only Tomcat and not some
> other component at the same time (e.g. Spring)?
>
> > I ditched the spring's usage of finding jndi resource and used the
> > initContext to lookup the JNDI resource and it worked fine.
>
> That suggests to me that the JNDI context is correctly-configured by
> Tomcat, and the problem lies within your configuration (likely) or
> Spring itself (unlikely).
>
> > I have to use spring to find the JNDI
> > context since most of our applications are already using spring and if i
> > need to change every single one of them it is a tedious process.
> >
> > We also have a unix environment that I tested this with and I didn't find
> > any issues there. i.e., I used spring to load the jndi resource, tomcat
> > 8.x, java 7, axis2 1.6.3.
> > Since this is a windows only issue, I tried to upgrade to Tomcat 9.x and
> > that resulted in the same error.
> > I have also posted this issue on the stackoverflow site but haven't had
> > much luck finding a solution to the issue.
> >
> http://stackoverflow.com/questions/36207119/tomcat-8-axis2-webservices-aar-spring-jndi-not-bound-in-context
>
> What is your  configuration in Tomcat, and how are you
> specifying your JNDI DataSource name in your Spring configuration?
>
> What do the (Spring) logs say?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
[INFO] Refreshing 
org.springframework.context.support.ClassPathXmlApplicationContext@67aa1e71: 
startup date [Tue Apr 26 22:36:49 EDT 2016]; root of context hierarchy
[INFO] Loading XML bean definitions from class path resource [DST-Context.xml]
[WARN] Exception encountered during context initialization - cancelling refresh 
attempt: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'datasource': Invocation of init method failed; nested 
exception is javax.naming.NameNotFoundException: Name [jdbc/ADS] is not bound 
in this Context. Unable to find [jdbc].
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'datasource': Invocation of init method failed; nested exception is 
javax.naming.NameNotFoundException: Name [jdbc/ADS] is not bound in this 
Context. Unable to find [jdbc].
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at 

Re: OT: Re: Order of attributes significant in zipfileset?

[Dave Glasser]

Good to know! Thanks George!


  From: George Sexton 
 To: Tomcat Users List  
 Sent: Tuesday, April 26, 2016 4:06 PM
 Subject: OT: Re: Order of attributes significant in zipfileset?
   
This isn't as bad as the delete task.

If you specify dir and file, it will delete everything in dir, not just 
file.


   

Re: Order of attributes significant in zipfileset?

[Dave Glasser]

  From: "Caldarale, Charles R" 
 To: Tomcat Users List ; Dave Glasser 
 
 Sent: Tuesday, April 26, 2016 2:32 PM
 Subject: RE: Order of attributes significant in zipfileset?
   
>> From: Dave Glasser [mailto:dglas...@pobox.com]
>> Subject: Order of attributes significant in zipfileset?
>
>> If you have a  element with both a dir and a file attribute, it 
>> will produce
>> different results depending on the order in which those attributes appear.
>
>Not surprising.

Really? Not surprising at all? I've never encountered a piece of software where 
the order of attributes on an input XML document mattered. AFAICT, you can't 
enforce the order of attribute names through a DTD or schema. Even W3C says 
"Notethat the order of attribute specifications in a start-tag or 
empty-elementtag is not significant." So, to me, it's quite surprising to 
encounter a situation where the order of attributes makes such a dramatic (but 
non-obvious) difference.

>> I want to make clear that I'm aware that the docs for fileset say:
>> "Either dir or file must be specified" and that I might be doing it wrong. 
>> You could argue
>> otherwise, but perhaps that does in fact unambiguously imply that having 
>> both is incorrect
>> and hence the behavior is undefined.
>
>
>Yes, it's undefined.  The file attribute is documented as a "shortcut for 
>specifying a single-file fileset" - you should not use both dir and file.  If 
>you want a single file in a particular directory, use just the file attribute:
>
>
Yep, that's pretty much what I figured. Or just use the includes attribute 
instead of file. That seems to work the way you'd expect it to, and the 
documentation is clear and unambiguous. I was just hoping maybe someone had 
some deeper information on this beyond an interpretation of the documents.


  

OT: Re: Order of attributes significant in zipfileset?

[George Sexton]

This isn't as bad as the delete task.

If you specify dir and file, it will delete everything in dir, not just 
file.


On 4/26/2016 12:18 PM, Dave Glasser wrote:

I discovered this in ant 1.6.5, and found that it still behaves this way in 
1.9.7.
If you have a  element with both a dir and a file attribute, it 
will produce different results depending on the order in which those attributes 
appear. If the file attribute appears first, it behaves as you would expect. For 
example, with this:

It looks for a file named "file1.txt" inside the directory "dir1". However, 
with this:

It looks for file1.txt inside the current working directory. This can be 
verified by running the demonstration target I provide below with the -debug 
switch, and reading the debug output.
I want to make clear that I'm aware that the docs for fileset say:
"Either dir or file must be specified" and that I might be doing it wrong. You 
could argue otherwise, but perhaps that does in fact unambiguously imply that having both 
is incorrect and hence the behavior is undefined. Be that as it may, what I would like to 
know is this:
Is this a known, and expected behavior?  Is it documented anywhere?
Should I assume that the order of attributes is significant in other places 
throughout my build.xml file?
Here's a self-contained target that demonstrates this behavior:
   
 

 
 
 
 
 

 
 

 
 
   
 

 
   
 

 
 

 
   
   
 

 
   

   
   
 

 Contents of ${ZIP1}:
 
   
   
 

 Contents of ${ZIP2}:
 
   
   
 
   




--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com

Re: Tomcat 8.0.28 and above

[Christopher Schultz]

Bhanu,

On 4/22/16 9:46 AM, bhanu lakkala wrote:
> I have been working on an issue for the past few days and wanted to check
> with you guys if you have any suggestions on fixing this issue.
> My current technology stack is: windows 7, java 7/8, tomcat 8, axis2 1.6.3.
> I have an axis2 based web service that is very basic and it just connects
> to a database and reads some info and spits out the info it read.
> I have setup a JNDI resource for the datasource.  In the service's init
> class's startup method, I am attempting to load the spring's
> ApplicationContext and thereby load the JNDI resource.
> All of this used to work well with the combination of java 7, tomcat 7.x
> axis2 1.6.3.
> Recently due to a need to upgrade to newer version of tomcat, I upgraded to
> tomcat 8. this resulted in "Name not found" exception.

I don't believe anything significant changed with Tomcat's handling of
JNDI DataSources. Are you sure you upgraded only Tomcat and not some
other component at the same time (e.g. Spring)?

> I ditched the spring's usage of finding jndi resource and used the
> initContext to lookup the JNDI resource and it worked fine.

That suggests to me that the JNDI context is correctly-configured by
Tomcat, and the problem lies within your configuration (likely) or
Spring itself (unlikely).

> I have to use spring to find the JNDI
> context since most of our applications are already using spring and if i
> need to change every single one of them it is a tedious process.
>
> We also have a unix environment that I tested this with and I didn't find
> any issues there. i.e., I used spring to load the jndi resource, tomcat
> 8.x, java 7, axis2 1.6.3.
> Since this is a windows only issue, I tried to upgrade to Tomcat 9.x and
> that resulted in the same error.
> I have also posted this issue on the stackoverflow site but haven't had
> much luck finding a solution to the issue.
> http://stackoverflow.com/questions/36207119/tomcat-8-axis2-webservices-aar-spring-jndi-not-bound-in-context

What is your  configuration in Tomcat, and how are you
specifying your JNDI DataSource name in your Spring configuration?

What do the (Spring) logs say?

-chris

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

Re: Tomcat 9.0.0-M4 seems not to start digest algorithm on JDBC Realm as did tomcat 8.0.25

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fabio,

On 4/24/16 11:36 AM, Fabio Ricci wrote:
> appreciate the sunday answer (thank you).
> 
> To say the truth: I did read the documentation and the migration
> guide.
> 
> But since there are no examples in 
> http://tomcat.apache.org/tomcat-8.0-doc/config/credentialhandler.html,
>
> 
I did not manage to create my own implementation concreteness. That’s
> why I deared to ask the community.

What examples did you want to see? You don't have to write your own
credential handler (code)... just use one of those already present.
There aren't many choices. If you read the page you referenced above
(the CredentialHandler configuration page), you should be able to
build a  element that meets your requirements quite
easily.

Were you hoping for a copy-and-paste solution?

If you were thinking of coming to ApacheCon in May, I'll plug my own
presentation which is all about CredentialHandlers -- and, in fact,
migrating away from simple MD5 hashes to much more secure forms of
credential-storage. Here's a reference to the abstract:

http://apachecon2016.sched.org/event/6OIs/seemless-upgrades-for-credenti
al-security-in-apache-tomcat-christopher-schultz-total-child-health?ifra
me=yes=i:0;=yes=no#?iframe=yes=i:0;=yes=no

(I don't seem to be able to get anyone to correct the typo in the
title. Hrmph.)

- -chris

>> On 24 Apr 2016, at 17:31, Mark Thomas  wrote:
>> 
>> On 22/04/2016 23:35, Fabio Ricci wrote:
>>> Dear tomcat Community
>>> 
>>> I am using cross context (which seems to be easy to configure
>>> but in in tomcat 8 hard to run) … so today I downloaded tomcat
>>> 9 and I migrated my apps to it. In tomcat 9 cross context is
>>> running smoothly (thank you!)
>>> 
>>> To authenticate my config is using JDBCRealm with a mysql
>>> database. The config below ran very well with tomcat 8 but on
>>> tomcat 9 accepted only the password digests (which are stored
>>> in the table tomcat_users) directly instead of the usual
>>> passwords. It seems that the digest algorithm MD5 be here not
>>> executed.
>> 
>> Given that the digest attribute doesn't exist on the Realm in
>> 9.0.x, that behaviour is as expected.
>> 
>> You should read the migration guide:
>> 
>> http://tomcat.apache.org/migration-9.html#Migrating_from_8.0.x_to_9.0
.x/Internal_APIs
>>
>>
>> 
If you had read the 8.0.x docs, you wouldn't have been using a
>> deprecated configuration option...
>> 
>> http://tomcat.apache.org/tomcat-8.0-doc/config/realm.html#Common_Attr
ibutes
>>
>>
>> 
... you would have been using the replacement configuration option.
>> 
>> http://tomcat.apache.org/tomcat-8.0-doc/config/credentialhandler.html
>>
>>
>>
>> 
Mark
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlcfyK4ACgkQ9CaO5/Lv0PDaQwCcDU1LlTw0L86FM1k6o2B7B1DB
PyEAniuDGebS+ePwlt+kVvu14wErGOAu
=QA8+
-END PGP SIGNATURE-

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

Failed to read schema document 'classpath:/schema/shibboleth-2.0-services.xsd'

[Hilbert, Colin]

Tomcat version 7.0.69
Also happens on 7.0.68 and 7.0.67

I don’t get this error on 7.0.65

I have deployed an idp.war on tomcat
The idp.war has a service.xml file that looks like this at the beginning:


http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="urn:mace:shibboleth:2.0:services 
classpath:/schema/shibboleth-2.0-services.xsd
  urn:mace:shibboleth:2.0:afp 
classpath:/schema/shibboleth-2.0-afp.xsd
  urn:mace:shibboleth:2.0:attribute:authority 
classpath:/schema/shibboleth-2.0-attribute-authority.xsd
  urn:mace:shibboleth:2.0:resolver 
classpath:/schema/shibboleth-2.0-attribute-resolver.xsd
  urn:mace:shibboleth:2.0:idp:profile-handler 
classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd
  urn:mace:shibboleth:2.0:relying-party 
classpath:/schema/shibboleth-2.0-relying-party.xsd
  urn:mace:shibboleth:2.0:resource 
classpath:/schema/shibboleth-2.0-resource.xsd”>

The stack complains that it cannot find the first schemaLocation listed but if 
I go to the deployed idp folder in tomcat idp/WEB-INF/lib/ there are jars 
there, one of which is shibboleth-common-1.2.1.jar

Which has the path /schema/ containing all those listed schemaLocations from 
the service.xml

I can move all the jars from idp/WE-INF/lib/ to tomcat7.0.69/lib/ and the 
exception goes away but I haven’t had to do this prior to .67

Can anyone shed some light on this?

Re: [OT] Order of attributes significant in zipfileset?

[Christopher Schultz]

Dave,

Off-topic, but okay.

On 4/26/16 2:18 PM, Dave Glasser wrote:
> I discovered this in ant 1.6.5, and found that it still behaves this way in 
> 1.9.7.
> If you have a  element with both a dir and a file attribute, it 
> will produce different results depending on the order in which those 
> attributes appear. If the file attribute appears first, it behaves as you 
> would expect. For example, with this:
> 
> It looks for a file named "file1.txt" inside the directory "dir1". However, 
> with this:
> 
> It looks for file1.txt inside the current working directory. This can be 
> verified by running the demonstration target I provide below with the -debug 
> switch, and reading the debug output.
> I want to make clear that I'm aware that the docs for fileset say:
> "Either dir or file must be specified" and that I might be doing it wrong. 
> You could argue otherwise, but perhaps that does in fact unambiguously imply 
> that having both is incorrect and hence the behavior is undefined. Be that as 
> it may, what I would like to know is this:
> Is this a known, and expected behavior?  Is it documented anywhere?

I think anything not documented should be considered "undefined".

I tend to agree with you, however, that the order of the attributes
effect the behavior is a little surprising.

> Should I assume that the order of attributes is significant in other places 
> throughout my build.xml file?
> Here's a self-contained target that demonstrates this behavior:
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>message="A file named file1.txt exists in the current directory.">
>   
> 
> 
>message="A file named file2.txt exists in the current directory.">
>   
> 
> 
> 
> 
> 
> 
>   
>   
> 
> 
> 
>   
> 
>   
>   
> 
> 
> Contents of ${ZIP1}:
> 
>   
>   
> 
> 
> Contents of ${ZIP2}:
> 
>   
>   
> 
>   
> 
> 

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

Re: OT if/else or not if/else

[Christopher Schultz]

Chuck,

On 4/26/16 12:18 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
>> Subject: Re: OT if/else or not if/else
> 
>> Unless the JIT can prove that there are no side-effects, it's not
>> going to perform any speculative computations for a possible branch.
> 
> True, but due to inlining of many methods, the side effects are often 
> visible.  It's quite common for compilers to generate reads out of order when 
> it can be proven they are not impacted by any subsequent write operations.
> 
>> it's not easy to decide if either of those two methods have any
>> side-effects.
> 
> Actually, given the JVM architecture, it is quite easy - the 
> compiler (the real one, not javac) has the callee method
> implementation available when it's processing the caller. This is not
> true with most languages. If a subsequent class definition
> invalidates such a determination, the compiler deoptimizes the
> generated method, and, if needed, recompiles it.

The compiler would have to invalidate that side-effect cache every time
a new class was used for that particular shouldDoSomething method gets
called, since it could be overridden at any time, so the callee's method
cannot (always) be known in advance. This is why, below, I mentioned
private and final methods. Those are known knowns, so coin a phrase.

I've never written a compiler (JIT) and all of these things are great
optimizations if they don't become bottlenecks, but I guess it's up to
the compiler writers to decide when enough is enough. Then again, JIT
work is constantly being done, so I suppose these days, they are quite
smart. When you gotta compete with native C, the JIT had better be good ;)

>> If the method is private or final in the declared type,
>> it can be evaluated completely, but that's a somewhat rare case.
> 
> Nope (see above).
> 
>> Presumably, the if-without-else case would actually free the compiler
>> to evaluate those predicates "early", but that wouldn't be considered
>> "speculative" in my mind because those side-effects would have
>> happened anyway (since all branches will be evaluated).
> 
> Only certain reads can be issued in such instances, since any writes
> are expected to be in order (unless you're dealing with the rather
> bonkers C++ memory model). The predicate evaluation isn't speculative,
> but reads from inside the predicated area are often lifted out of the
> blocks, and it's these that are speculative.

Agreed. I was more concerned with writes. Any time you can have your CPU
doing anything other than NOPs, you should be. Speculative reads are
pretty much always a good idea.

>> The only potential problem would be with an early branch that throws an
>> exception, in which case any side-effects of a later predicate would
>> be ... surprising.
> 
> If a predicate evaluation might cause a write, it pretty much
> precludes looking at them out of order.

Exactly. This just goes back to how much work the compiler (JIT) is
willing to investigate and how complex the predicate (or branch itself)
might actually be. Because not only must the predicates be read-only,
anything you might want to execute ahead of time within the branch needs
to be read-only as well.

The smarter the compiler, the better performance you can get. Compilers
these days are strikingly smart, and can prove things that even the most
seasoned high-level-language (e.g. Java) programmer might stay away from
because it's risky, or perhaps just plain difficult to read. That's one
of the great things about languages with JITs (instead of
pre-processors) instead of traditional compilers (e.g. C): the JIT can
take nice, maintainable, good-looking code and turn it into a complete
mess of internal code that has equivalent runtime meaning, but with
better performance than a naive or straightforward implementation of the
high-level language.

I like Olaf's saw: "optimize for the maintainer, not the compiler." The
compiler is smarter than you, anyway, so you may as well write your code
so that humans can understand it. ;)

-chris

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

Re: Tomcat 8.5 Nio2: java.lang.IllegalStateException: Failed to create Processor for negotiated protocol [""]

[Mark Thomas]

On 25/04/2016 17:10, Kreuser, Peter wrote:
> Hi there,
> 
> I have setup Tomcat 8.5 with the all new SSL Config and HTTP/2.
> 
> To test the setup I use testssl.sh (https://testssl.sh ) . The scan is 
> successful, also stating HTTP/2 is working. So far so good.
> 
> However I see the following exception in the Logs:
> 
> 25-Apr-2016 17:36:16.697 SEVERE [https-nio2-8443-exec-6] 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process Error reading 
> request, ignored
> java.lang.IllegalStateException: Failed to create Processor for negotiated 
> protocol [""]
> at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:736)
> at 
> org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1699)
> at 
> org.apache.tomcat.util.net.Nio2Endpoint.processSocket0(Nio2Endpoint.java:397)
> at 
> org.apache.tomcat.util.net.Nio2Endpoint.processSocket(Nio2Endpoint.java:382)
> at 
> org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:115)
> at 
> org.apache.tomcat.util.net.SecureNio2Channel$HandshakeWriteCompletionHandler.completed(SecureNio2Channel.java:108)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
> at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)
> at 
> sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)
> at 
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)
> at 
> sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)
> at 
> java.nio.channels.AsynchronousSocketChannel.write(AsynchronousSocketChannel.java:577)
> at 
> org.apache.tomcat.util.net.SecureNio2Channel.handshakeInternal(SecureNio2Channel.java:273)
> at 
> org.apache.tomcat.util.net.SecureNio2Channel.handshake(SecureNio2Channel.java:204)
> at 
> org.apache.tomcat.util.net.Nio2Endpoint$SocketProcessor.run(Nio2Endpoint.java:1676)
> at 
> org.apache.tomcat.util.net.Nio2Endpoint.processSocket0(Nio2Endpoint.java:397)
> at 
> org.apache.tomcat.util.net.Nio2Endpoint.processSocket(Nio2Endpoint.java:382)
> at 
> org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:98)
> at 
> org.apache.tomcat.util.net.SecureNio2Channel$HandshakeReadCompletionHandler.completed(SecureNio2Channel.java:91)
> at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
> at sun.nio.ch.Invoker$2.run(Invoker.java:218)
> at 
> sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> 
> The sourcecode of AbstractProtocol.java states:
> 
> if (processor == null) {
> String negotiatedProtocol = 
> wrapper.getNegotiatedProtocol();
> if (negotiatedProtocol != null) {
> UpgradeProtocol upgradeProtocol =
> 
> getProtocol().getNegotiatedProtocol(negotiatedProtocol);
> if (upgradeProtocol != null) {
> processor = upgradeProtocol.getProcessor(
> wrapper, getProtocol().getAdapter());
> } else if (negotiatedProtocol.equals("http/1.1")) {
> // Explicitly negotiated the default protocol.
> // Obtain a processor below.
> } else {
> // Failed to create processor. This is a bug.
> throw new IllegalStateException(sm.getString(
> 
> "abstractConnectionHandler.negotiatedProcessor.fail",
> negotiatedProtocol));
> }
> }
> }
> 
> So why is this a bug? Should I change something or should Mark T. look into 
> it?

I don't have exclusive rights for investigating potential Tomcat bugs
you know (although I do have the advantage that a large proportion of my
$dayjob is doing exactly that).

This is on my radar but I'd love to see someone else (I'm looking at you
Peter) take a look. My suggestion is to find out:
a) what protocols Tomcat is advertising
b) what protocols the client is 

RE: Order of attributes significant in zipfileset?

[Caldarale, Charles R]

> From: Dave Glasser [mailto:dglas...@pobox.com] 
> Subject: Order of attributes significant in zipfileset?

> If you have a  element with both a dir and a file attribute, it 
> will produce 
> different results depending on the order in which those attributes appear.

Not surprising.

> I want to make clear that I'm aware that the docs for fileset say:
> "Either dir or file must be specified" and that I might be doing it wrong. 
> You could argue 
> otherwise, but perhaps that does in fact unambiguously imply that having both 
> is incorrect 
> and hence the behavior is undefined. 

Yes, it's undefined.  The file attribute is documented as a "shortcut for 
specifying a single-file fileset" - you should not use both dir and file.  If 
you want a single file in a particular directory, use just the file attribute:



 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.



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

Order of attributes significant in zipfileset?

[Dave Glasser]

I discovered this in ant 1.6.5, and found that it still behaves this way in 
1.9.7.
If you have a  element with both a dir and a file attribute, it 
will produce different results depending on the order in which those attributes 
appear. If the file attribute appears first, it behaves as you would expect. 
For example, with this:

It looks for a file named "file1.txt" inside the directory "dir1". However, 
with this:

It looks for file1.txt inside the current working directory. This can be 
verified by running the demonstration target I provide below with the -debug 
switch, and reading the debug output.
I want to make clear that I'm aware that the docs for fileset say:
"Either dir or file must be specified" and that I might be doing it wrong. You 
could argue otherwise, but perhaps that does in fact unambiguously imply that 
having both is incorrect and hence the behavior is undefined. Be that as it 
may, what I would like to know is this:
Is this a known, and expected behavior?  Is it documented anywhere?
Should I assume that the order of attributes is significant in other places 
throughout my build.xml file?
Here's a self-contained target that demonstrates this behavior:
  
    

    
    
    
    
    

    
    

    
    
  
    

    
  
    

    
    

    
  
  
    

    
  

  
  
    

    Contents of ${ZIP1}:
    
  
  
    

    Contents of ${ZIP2}:
    
  
  
    
  

RE: OT if/else or not if/else

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: OT if/else or not if/else

> Unless the JIT can prove that there are no side-effects, it's not
> going to perform any speculative computations for a possible branch.

True, but due to inlining of many methods, the side effects are often visible.  
It's quite common for compilers to generate reads out of order when it can be 
proven they are not impacted by any subsequent write operations.

> it's not easy to decide if either of those two methods have any
> side-effects.

Actually, given the JVM architecture, it is quite easy - the compiler (the real 
one, not javac) has the callee method implementation available when it's 
processing the caller.  This is not true with most languages.  If a subsequent 
class definition invalidates such a determination, the compiler deoptimizes the 
generated method, and, if needed, recompiles it.

> If the method is private or final in the declared type,
> it can be evaluated completely, but that's a somewhat rare case.

Nope (see above).

> Presumably, the if-without-else case would actually free the compiler
> to evaluate those predicates "early", but that wouldn't be considered
> "speculative" in my mind because those side-effects would have
> happened anyway (since all branches will be evaluated).

Only certain reads can be issued in such instances, since any writes are 
expected to be in order (unless you're dealing with the rather bonkers C++ 
memory model).  The predicate evaluation isn't speculative, but reads from 
inside the predicated area are often lifted out of the blocks, and it's these 
that are speculative.

> The only potential problem would be with an early branch that throws an
> exception, in which case any side-effects of a later predicate would
> be ... surprising.

If a predicate evaluation might cause a write, it pretty much precludes looking 
at them out of order.

 - Chuck


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

Re: Small problems compiling tomcat native

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rainer,

On 4/25/16 8:57 AM, Rainer Jung wrote:
> Am 25.04.2016 um 14:31 schrieb Stefan Frei:
>> very sorry just solved it.
>> 
>> 
>> overlooked a line in configure
>> 
>> /root/tomcat-native-1.1.34-src/jni/native/build/get-version.sh: 
>> Permission denied
> 
> OK, no problem. If extracted from a source tarball, the file should
> have been executable by default though. It might be it is not if
> you picked a zip file source download.
> 
> Another comment: OpenSSL 1.0.1k is pretty old.

Debian has "stable" versions plus patches. So for example, my Debian
system currently reports OpenSSL 1.0.1e which is (by version number)
before Heartbleed was fixed. But if I ask Debian what the version of
the package is, it tells me:

1.0.1e-2+deb7u20

So there have been something like 20 patches against their stable
version, but they still maintain the version that was initially
released. So, even though "openssl version" reports:

$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

It actually contains all of the "important" patches that have been
released since then (for whatever definition the Debian security team
has for "important").

> 1.0.1s is current for 1.0.1 and even better would be 1.0.2g but it
> might be, that you won't find such a packet for your OS version.

The nice thing about Debian is that it's super stable, in every sense
of the word. The bad thing about Debian is that it's super stable, in
every sense of the word.

> You could compile 1.0.2g yourself though and install in a separate
> directory. Using 1.0.2 you could switch to tcnative 1.2.x (which
> needs OpenSSL 1.0.2).

This is entirely possible, and it's how I perform my own testing for
tcnative releases (since they currently require 1.0.2).

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlcfkUcACgkQ9CaO5/Lv0PC/8ACgi9siQitWZ5I2bU4ReOBH7K2N
mywAnj5oj9Pxu69j++1CRCn9oMd8Qyfw
=N/WQ
-END PGP SIGNATURE-

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

Re: thread recovery

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mahudeswaran,

On 4/25/16 2:03 AM, Mahudeswaran A wrote:
> Let's assume mutex.wait being called in one of the tomcat thread. 
> The thread state is still RUNNABLE but the thread does nothing and 
> just waiting.
> 
> Is there any functionality in tomcat to automatically recovery for 
> these threads either through some configurations? For e.g. if
> there are threads in the same state for more than 7 or 8 hours...

If Tomcat code is wait for hours (and it's a problem), then it's a bug
in Tomcat. I think that's rather unlikely.

If you have Object.wait() calls in your own code, perhaps what you
really want to do is change those to Object.wait(timeout) with a
sufficiently long timeout not to cause any performance problems, but
which can allow a thread to "recover" even if the mutex never received a
notify() call.

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

iEYEARECAAYFAlcfj54ACgkQ9CaO5/Lv0PAGGwCgmhUYGT6YUIA0eZgBdSO8vG0m
UsIAnjMXV9vf/OuLZ+x6fv4yGmOQJ7dV
=Y7Ri
-END PGP SIGNATURE-

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

Re: OT if/else or not if/else

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 4/25/16 4:54 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
>> Subject: Re: OT if/else or not if/else
> 
>> If you use else-less-if, then there is never an opportunity for 
>> parellelization, since the program is going to assume that those 
>> predicates are (a) independent and (b) ordered in a way that the 
>> programmer intended.
> 
> Not quite true. Modern compilers and CPU cores will speculatively 
> execute code sequences in parallel that may later be abandoned when
> the results of predicate evaluation are available; this can be done
> for both the if-else-if and the else-less-if forms. Regardless, the
> if-else-if form is much preferred, in terms of providing both the
> compiler and the maintainer with more information (and is certainly
> not premature optimization, by any stretch of the imagination).

Unless the JIT can prove that there are no side-effects, it's not
going to perform any speculative computations for a possible branch.
Many structures are of the form:

if(somethingIsTrue()) {
   ...
} elseif(somethingElseIsTrue()) {
   ...
}
...

and it's not easy to decide if either of those two methods have any
side-effects. If the method is private or final in the declared type,
it can be evaluated completely, but that's a somewhat rare case.

Presumably, the if-without-else case would actually free the compiler
to evaluate those predicates "early", but that wouldn't be considered
"speculative" in my mind because those side-effects would have
happened anyway (since all branches will be evaluated). The only
potential problem would be with an early branch that throws an
exception, in which case any side-effects of a later predicate would
be ... surprising.

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

iEYEARECAAYFAlcfjI4ACgkQ9CaO5/Lv0PBqvwCgiap/UoI6/slICwUCQtZOYjjq
af0AoJZ8e5qy9yUy3shqblCJJ2cRL2Ls
=TTKq
-END PGP SIGNATURE-

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