Re: Interface default methods

2014-07-03 Thread Mark Thomas
On 3 July 2014 04:11:32 GMT+01:00, Leo Donahue donahu...@gmail.com wrote:
I don't want to start a war, but just curious if the Tomcat developers
see
any use case for adding default methods to any of the Interfaces in the
API?

Which API?

Mark



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



RE: Apache Tomcat7 service start randomly after the installation of McAfee antivirus.

2014-07-03 Thread Blachon, Philippe
Good morning,

Yes, it was random occasions where Tomcat appears not to re-start .

Finally we have excluded from McAfee scanning : Tomcat7.exe, Java.exe and .zip 
files. As the launched application is Java opening a 3.5 Go .zip file surely 
the server was too busy to launch Tomcat and scan all that.
Everything has worked fine for the last 2 days ;)

Thanks for the help.
Philippe .

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, July 01, 2014 3:48 PM
To: Tomcat Users List
Subject: Re: Apache Tomcat7 service start randomly after the installation of 
McAfee antivirus.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Philipe,

On 7/1/14, 3:57 AM, Blachon, Philippe wrote:
 We have 4 identical servers with a scheduled task running every night 
 on each of them. This task Stop Tomcat - Update some data - Start 
 Tomcat.

 This worked fine for months.

 We have installed a new antivirus McAfee 3 weeks ago. Now the
 Tomcat7 service starts randomly. At least 1 of the 4 server needs a 
 manual start of the Tomcat7 service every morning.

So the service starts randomly (spontaneously), or there are random occasions 
where Tomcat appears not to re-start after the scheduled stop/start dance? It 
sounds like the latter.

Anything in the log files indicating that Tomcat even /tried/ to start?

 Do you know if there is specifics problems between Tomcat and McAfee?

None that I know of.

 We have already tried to exclude Tomcat.exe from McAfee scanning.
 Is there other thing we could exclude without compromising the 
 security?

 Configuration: Windows server 2008 R2 Standard - SP1 Apache Tomcat
 7.0.29 Server McAffee Agent 4.8.0.1500 Mcafee VirusScan Enterprise
 8.8.04001

You should check the log files -- likely something like catalina* in your 
logs directory. The filename can be changed in the service runner, so the file 
does not necessarily have a predictable name.

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

iQIcBAEBCAAGBQJTsrwCAAoJEBzwKT+lPKRYIz8QAK3Z5+/7KQdSvtGKNuAC8+Zb
27FCOb6yQfE1YgYW0bw7GFER49asPis1WSBi/NzTPFVlnoaq3WUB+jUyASUtWZj6
pLllaVgHP2TSAQd90K6MJb83Iva+Oszas85jR2H/eNAitJRD0u3YePkllF+bBkPb
yI8pGY4qWkCCV+0m/cdscaj4EmzH0cI7HIc0fvxQw4aluDXmcDi8WoyEU2WV95wW
30h82BUs4aeuUb7LY6v+HNfwqPfhbiiPVhRW7q0u17PXk/FCOhIfLLG31FaYqpkO
Md56Sbh4xQ6KRSTSZG19Kls18LxM0qcHHk5CZtUtuBryk1PlcdMvKq9G/dDjUT5W
dKPs6nff/Cg/0O/16mMTp7HsxZl8choBUPy/hXAD4hyPWM5FPweGmGSg0rF1dhH2
M8v76Cdl2uwjuXlLH6qD6wmTEKh+00n1eGLLYTOX4bOGPS1+ugtdnD/NM1R7ean3
77kO5st+w2X/NeziBzhPNW9QJ1UJ7fGE/wZjR5U8aj/+XulUpTY9uoqi6TisBLvt
nP4JAXsh+SosCFK3NJgECJ02dMwbgnE5Dnk0g4uZ708MxotZQYNY71l1qJMCRHhz
cuRgywJF14suO3UhYVcgbsmO3uFchrf4bZFXk5m8UeIbzJytgZbvCnjo61FuTHz3
VOM85Bsk81WU5MQpL2Vu
=wBcZ
-END PGP SIGNATURE-

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


Please consider the environment before printing this email or its 
attachment(s).  Please note that this message may contain confidential 
information.  If you have received this message in error, please notify me and 
then delete it from your system.


Re: [somewhat OT] Apache Tomcat7 service start randomly after the installation of McAfee antivirus.

2014-07-03 Thread André Warnier

Leo Donahue wrote:

On Wed, Jul 2, 2014 at 2:33 AM, André Warnier a...@ice-sa.com wrote:


Blachon, Philippe wrote:


Good morning,

We have 4 identical servers with a scheduled task running every night on
each of them. This task Stop Tomcat - Update some data - Start Tomcat.
This worked fine for months.
We have installed a new antivirus McAfee 3 weeks ago. Now the Tomcat7
service starts randomly. At least 1 of the 4 server needs a manual start of
the Tomcat7 service every morning.

Do you know if there is specifics problems between Tomcat and Mc Afee ?
We have already tried to exclude Tomcat.exe from McAfee scanning. Is
there other thing we could exclude without compromising the security ?

Configuration:
Windows server 2008 R2 Standard - SP1
Apache Tomcat 7.0.29 Server
McAffee Agent 4.8.0.1500
Mcafee VirusScan Enterprise 8.8.04001

Thanks, have a nice day,
Philippe Blachon.



Not a direct answer to your question, but maybe a bit of lateral and
logical thinking here :

Why would one run a virus scanner permanently on a Tomcat server ?



Does the OP work in the government?  My former employer had virus scanning
software on every server.  You couldn't get a server image without it.

The answer to that question is really based on policy, if he works in
government.  Eventually, that server has the potential for getting a virus
somehow from something or someone, and someone has to answer the question:
why wasn't there virus scanning software on the server?



Leo, I understand what you're saying above.
But if one extrapolates that logic, then at some point the whole IT infrastructure and the 
whole Internet would grind to a halt, as only the POTUS would be allowed to upload 
anything onto a computer.



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



Re: Silent failure to deploy or run from configuration descriptor

2014-07-03 Thread Konstantin Kolinko
2014-07-03 0:38 GMT+04:00 Gulliver Smith gulliver.m.sm...@gmail.com:
 Apache Tomcat/7.0.28, Debian

 I have two configuration descriptors in /etc/tomcat7/Catalina/localhost/

 One, solr.xml deploys correctly and fills catalina.out with lots of
 useful messages.


 The other fails silently to start (see below).

 I see the message INFO: Deploying configuration descriptor in
 catalina.out; then there is nothing else in catalina.out.


1. Try with an up-to-date version of 7.0. (Such as 7.0.42 or 7.0.54).

2. If you use docBase=xxx/foo.war  Tomcat 6 will unpack the war file
into docbase directory.

Early versions of Tomcat 7 do not unpacked the war file and run it as is.
Unpacking was reimplemented starting with 7.0.48 (BZ 51294)

Is your application able to run from an non-unpacked war?

3. catalina.out is not a proper log file. That is just catch of
console output.

What is in other log files (localhost.date.log)?

4. Scanning for annotations in a web application may take noticeable time.
http://wiki.apache.org/tomcat/HowTo/FasterStartUp

Take a thread dump and see what background thread is doing.

Do you have other symptoms of whether the application has been
deployed? Is its directory created in Tomcat's work directory? Is it
listed in manager webapp? Does it respond to HTTP requests?

 (...)


Best regards,
Konstantin Kolinko

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



RE: Error in DBCP Connection Pool with tomcat 6.x

2014-07-03 Thread Vijendra Pachoriya
Thanks everyone !!

Managed to solve the issue. It seems the wait time out for db was less than 
that of configured in tomcat.

Which was leading to close the connection before tomcat does it.
 
Regards,
Vijendra


-Original Message-
From: Phil Steitz [mailto:phil.ste...@gmail.com] 
Sent: 02 July 2014 22:33
To: Tomcat Users List
Subject: Re: Error in DBCP Connection Pool with tomcat 6.x

On 7/1/14, 10:48 PM, Vijendra Pachoriya wrote:
 Hi Filip,

 This error comes at some point of time on production, when the server is on 
 load.

 I am using hibernate and not closing any connection manually, its all managed 
 by hibernate and tomcat dbcp connection pool.

Two additional things to check:

1) Check logs to see if abandoned connections are being removed.  If your code 
is closing all connections, you should not need this to be enabled.
2) Make sure that there is no sharing across threads of the Hibernate objects.

Phil

 For me it seems like DBCP is trying to close the connection which is already 
 closed by the database server.

 Please refer below related links.

 https://issues.apache.org/jira/browse/DBCP-329

 http://markmail.org/message/c2gx2xuzum4pv743#query:+page:1+mid:ncvixx4
 ewe7pho2x+state:results


 Regards,
 Vijendra

 -Original Message-
 From: Filip Hanik [mailto:fi...@hanik.com]
 Sent: 01 July 2014 21:06
 To: Tomcat Users List
 Subject: Re: Error in DBCP Connection Pool with tomcat 6.x

 Looks like your code already called java.sql.Connection.close() and 
 then attempts to use the connection again

 Filip



 On Tue, Jul 1, 2014 at 8:09 AM, Propes, Barry L 
 barry.l.pro...@citi.com
 wrote:


 -Original Message-
 From: Vijendra Pachoriya [mailto:vijendra.pachor...@indegene.com]
 Sent: Tuesday, July 01, 2014 2:31 AM
 To: users@tomcat.apache.org
 Cc: Alok Roy
 Subject: Error in DBCP Connection Pool with tomcat 6.x

 Hi Tomcat Team,

 Please help me out in solving below error.

 Below is the details :

 Configuration in my
 context.xml


 Resource name=jdbc/ABC
 auth=Container
 type=javax.sql.DataSource
 maxActive=50
 maxIdle=10
 maxWait=1
 username=ABC
 password=ABC
 removeAbandoned=true
 logAbandoned=true
 testOnBorrow=true
 testWhileIdle=true
 timeBetweenEvictionRunsMillis=3
 validationQuery=SELECT 1 FROM dual
 driverClassName=oracle.jdbc.driver.OracleDriver
 url=jdbc:oracle:thin:@MY_DB /


 ==Error Message 
 

 at
 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
 at
 org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
 at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
 at java.lang.Thread.run(Thread.java:679)
 Caused by: org.springframework.transaction.TransactionSystemException:
 Could not roll back JPA transaction; nested exception is
 javax.persistence.PersistenceException: unexpected error when rollbacking
 at
 org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:486)
 at
 org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:800)
 at
 org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:777)
 at
 org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:339)
 at
 org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
 at
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
 at
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at sun.proxy.$Proxy185.selectPharmaUser(Unknown Source)
 at
 com.aptilon.axcelrx.server.service.impl.AuthenticationServiceImpl.login(AuthenticationServiceImpl.java:170)
 at
 com.aptilon.axcelrx.server.ws.endpoint.AuthenticationEndpoint.login_aroundBody0(AuthenticationEndpoint.java:110)
 ... 45 more
 Caused by: javax.persistence.PersistenceException: unexpected error 
 when rollbacking
 at
 org.hibernate.ejb.TransactionImpl.rollback(TransactionImpl.java:88)
 at
 org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:482)
 ... 54 more
 Caused by: org.hibernate.exception.GenericJDBCException: Cannot 
 release connection
 at
 org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126)
 at
 org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114)
 at
 

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hello Mark

Thanks for your answer. I put the new information and cluster works (maybe
because I reboot my machine)

Indeed, I'm trying BIO because NIO is causing session replication issues on
load tests. Using NIO, I've already tried to increase maxThreads, and this
minimizes the problem, but don't solve it.

Thanks


2014-07-02 13:28 GMT-03:00 Mark Eggers its_toas...@yahoo.com.invalid:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/2/2014 6:37 AM, João Sávio wrote:
  ?
 
 
  2014-06-30 18:38 GMT-03:00 João Sávio joaosa...@gmail.com:
 
  Hello people
 
  This is my first message on this group! I'm trying to set up a
  Tomcat clustering using BIO receiver but I've been receiving the
  following error when I started two nodes and tried to enter on my
  application:
 
  Jun 30, 2014 9:25:12 PM
  org.apache.catalina.tribes.transport.bio.BioReplicationT ask run
  SEVERE: Unable to service bio socket
  java.net.SocketTimeoutException: Read timed out at
  java.net.SocketInputStream.socketRead0(Native Method) at
  java.net.SocketInputStream.read(SocketInputStream.java:152) at
  java.net.SocketInputStream.read(SocketInputStream.java:122) at
  java.net.SocketInputStream.read(SocketInputStream.java:108) at
  org.apache.catalina.tribes.transport.bio.BioReplicationTask.drainSock
 
 
 et(BioReplicationTask.java:146)
  at
  org.apache.catalina.tribes.transport.bio.BioReplicationTask.run(BioRe
 
 
 plicationTask.java:64)
  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)
 
  Jun 30, 2014 9:25:15 PM
  org.apache.catalina.ha.session.DeltaManager startInternal INFO:
  Register manager localhost#/myApp to cluster element Engine with
  name Catalina Jun 30, 2014 9:25:15 PM
  org.apache.catalina.ha.session.DeltaManager startInternal INFO:
  Starting clustering manager at localhost#/myApp Jun 30, 2014
  9:25:15 PM org.apache.catalina.ha.session.DeltaManager
  getAllClusterSessions INFO: Manager [localhost#/myApp],
  requesting session state from
  org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 212,
  191, 209}:4000,{10, 212, 191, 2 09},4000, alive=32096,
  securePort=-1, UDP Port=-1, id={-58 95 -116 89 86 -12 714 -75 -2
  74 -45 -54 -82 40 -114 }, payload={}, command={}, domain={}, ].
  This operation will timeout if no session state has been received
  within 60 seconds.
 
 
  Attached are my two server.xml configuration. I've taken the
  default configuration (worked on my computer) and replaced the
  following things:
 
 
  Receiver
  className=org.apache.catalina.tribes.transport.nio.NioReceiver
  by Receiver
  className=org.apache.catalina.tribes.transport.bio.BioReceiver
 
  and
 
  Transport
 
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
 
 
 by
  Transport
  className=org.apache.catalina.tribes.transport.bio.PooledMultiSender/
 
 
 
 
 I don't know if I'm missing something. I'll be very thankful if someone
  can take a look on my server.xml files or send me an example
  configuration using BIO receiver (I couldn't find anyone).
 
  Thanks João -- http://joaosavio.wordpress.com

 João,

 Welcome to the list.

 I've only used NIO, and it's been a while since I've used clustering.

 A few questions to ask:

 1. Is there a firewall blocking port 4000 (if the Tomcats are on
separate machines)?
 2. Multicast enabled and routed?
 3. Environment (Tomcat version, java version, platforms)?
 4. Why BIO?

 What are you trying to accomplish by using the BIO connector rather
 than the NIO connector?

 You can turn on more logging by adding something like the following to
 logging.properties:

 # at the end of the handlers line:
 ,5cluster.org.apache.juli.FileHandler

 # in the handler-specific properties section:
 5cluster.org.apache.juli.FileHandler.level = FINER
 5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
 5cluster.org.apache.juli.FileHandler.prefix = cluster.

 # in the facility specific properties section
 # be aware of line wrapping
 org.apache.catalina.tribes.MESSAGES.level = FINE
 org.apache.catalina.tribes.MESSAGES.handlers =
 5cluster.org.apache.juli.FileHandler

 org.apache.catalina.tribes.level = FINE
 org.apache.catalina.tribes.handlers = 5cluster.org.apache.juli.FileHandler

 org.apache.catalina.ha.level = FINE
 org.apache.catalina.ha.handlers = 5cluster.org.apache.juli.FileHander

 org.apache.catalina.ha.deploy.level = INFO
 org.apache.catalina.ha.deploy.handlers =
 5cluster.org.apache.juli.FileHandler

 Last note - we're normally a pretty helpful bunch of folks here, but
 we are all volunteers. Things like work impact participation :-p. Also
 as noted above, I've only used NIO so I don't know why this would not
 work with BIO.

 . . . just my two cents
 /mde/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (MingW32)
 Comment: Using GnuPG with Thunderbird 

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Unfortunately it's not working yet

I increased the log level as you suggested. Log attached

Thanks



2014-07-03 11:10 GMT-03:00 João Sávio joaosa...@gmail.com:

 Hello Mark

 Thanks for your answer. I put the new information and cluster works (maybe
 because I reboot my machine)

 Indeed, I'm trying BIO because NIO is causing session replication issues
 on load tests. Using NIO, I've already tried to increase maxThreads, and
 this minimizes the problem, but don't solve it.

 Thanks


 2014-07-02 13:28 GMT-03:00 Mark Eggers its_toas...@yahoo.com.invalid:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/2/2014 6:37 AM, João Sávio wrote:
  ?
 
 
  2014-06-30 18:38 GMT-03:00 João Sávio joaosa...@gmail.com:
 
  Hello people
 
  This is my first message on this group! I'm trying to set up a
  Tomcat clustering using BIO receiver but I've been receiving the
  following error when I started two nodes and tried to enter on my
  application:
 
  Jun 30, 2014 9:25:12 PM
  org.apache.catalina.tribes.transport.bio.BioReplicationT ask run
  SEVERE: Unable to service bio socket
  java.net.SocketTimeoutException: Read timed out at
  java.net.SocketInputStream.socketRead0(Native Method) at
  java.net.SocketInputStream.read(SocketInputStream.java:152) at
  java.net.SocketInputStream.read(SocketInputStream.java:122) at
  java.net.SocketInputStream.read(SocketInputStream.java:108) at
  org.apache.catalina.tribes.transport.bio.BioReplicationTask.drainSock
 
 
 et(BioReplicationTask.java:146)
  at
  org.apache.catalina.tribes.transport.bio.BioReplicationTask.run(BioRe
 
 
 plicationTask.java:64)
  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)
 
  Jun 30, 2014 9:25:15 PM
  org.apache.catalina.ha.session.DeltaManager startInternal INFO:
  Register manager localhost#/myApp to cluster element Engine with
  name Catalina Jun 30, 2014 9:25:15 PM
  org.apache.catalina.ha.session.DeltaManager startInternal INFO:
  Starting clustering manager at localhost#/myApp Jun 30, 2014
  9:25:15 PM org.apache.catalina.ha.session.DeltaManager
  getAllClusterSessions INFO: Manager [localhost#/myApp],
  requesting session state from
  org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 212,
  191, 209}:4000,{10, 212, 191, 2 09},4000, alive=32096,
  securePort=-1, UDP Port=-1, id={-58 95 -116 89 86 -12 714 -75 -2
  74 -45 -54 -82 40 -114 }, payload={}, command={}, domain={}, ].
  This operation will timeout if no session state has been received
  within 60 seconds.
 
 
  Attached are my two server.xml configuration. I've taken the
  default configuration (worked on my computer) and replaced the
  following things:
 
 
  Receiver
  className=org.apache.catalina.tribes.transport.nio.NioReceiver
  by Receiver
  className=org.apache.catalina.tribes.transport.bio.BioReceiver
 
  and
 
  Transport
 
 className=org.apache.catalina.tribes.transport.nio.PooledParallelSender/
 
 
 by
  Transport
 
 className=org.apache.catalina.tribes.transport.bio.PooledMultiSender/
 
 
 
 
 I don't know if I'm missing something. I'll be very thankful if someone
  can take a look on my server.xml files or send me an example
  configuration using BIO receiver (I couldn't find anyone).
 
  Thanks João -- http://joaosavio.wordpress.com

 João,

 Welcome to the list.

 I've only used NIO, and it's been a while since I've used clustering.

 A few questions to ask:

 1. Is there a firewall blocking port 4000 (if the Tomcats are on
separate machines)?
 2. Multicast enabled and routed?
 3. Environment (Tomcat version, java version, platforms)?
 4. Why BIO?

 What are you trying to accomplish by using the BIO connector rather
 than the NIO connector?

 You can turn on more logging by adding something like the following to
 logging.properties:

 # at the end of the handlers line:
 ,5cluster.org.apache.juli.FileHandler

 # in the handler-specific properties section:
 5cluster.org.apache.juli.FileHandler.level = FINER
 5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
 5cluster.org.apache.juli.FileHandler.prefix = cluster.

 # in the facility specific properties section
 # be aware of line wrapping
 org.apache.catalina.tribes.MESSAGES.level = FINE
 org.apache.catalina.tribes.MESSAGES.handlers =
 5cluster.org.apache.juli.FileHandler

 org.apache.catalina.tribes.level = FINE
 org.apache.catalina.tribes.handlers = 5cluster.org.apache.juli.FileHandler

 org.apache.catalina.ha.level = FINE
 org.apache.catalina.ha.handlers = 5cluster.org.apache.juli.FileHander

 org.apache.catalina.ha.deploy.level = INFO
 org.apache.catalina.ha.deploy.handlers =
 5cluster.org.apache.juli.FileHandler

 Last note - we're normally a pretty helpful bunch of folks here, but
 we are all volunteers. Things like work impact participation :-p. Also
 as noted above, I've only used NIO so I don't know 

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Konstantin Kolinko
2014-07-03 18:46 GMT+04:00 João Sávio joaosa...@gmail.com:
 Unfortunately it's not working yet

 I increased the log level as you suggested. Log attached

 Thanks


Please read numbers 6. and 7. here:
http://tomcat.apache.org/lists.html#tomcat-users

The attachment was thrown away by the mail server.

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



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
I'd be more inclined to continue down the path of the NIO connector, it has
been tested and used more. What are the errors you get when running with
NIO?


On Thu, Jul 3, 2014 at 8:51 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 2014-07-03 18:46 GMT+04:00 João Sávio joaosa...@gmail.com:
  Unfortunately it's not working yet
 
  I increased the log level as you suggested. Log attached
 
  Thanks
 

 Please read numbers 6. and 7. here:
 http://tomcat.apache.org/lists.html#tomcat-users

 The attachment was thrown away by the mail server.

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




Re: Where can I store data files in a tomcat war

2014-07-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 7/2/14, 4:28 PM, Paul Taylor wrote:
 On 02/07/2014 16:34, Christopher Schultz wrote:
 
 The solution is that the web application, packaged in a WAR
 file, needs to unpack the Lucene indexes onto the disk when it
 starts up. You can do this with a ServletContextListener.
 
 So I do within init() method of my servlet, but EB doesnt wait for
 the init() method to finish before declaring the application ready,
 do you think it would wait for code using a ServletContextListener
 or fail in the same way it does for init() ?

Which init() are you talking about? If EB marks the cluster node as
available before the webapp has completed deploying, that sounds like
a big problem. If you are using servlet.init() without any
load-on-startup for that servlet, then I would expect the bad behavior
you describe. I think you'll have better luck with
ServletContextListener, because the servlet spec guarantees those to
be complete before the webapp can receive requests.

If EB allows requests to arrive before the deployment is complete,
basically nothing in EB would work properly.

 That would work, too, but you'll have to pay for download time
 for each member of the cluster. If you pack the indexes in the
 WAR file, they are already available when the webapp
 initializes.
 
 See my later posts, it doesn't work because of problem with EB not 
 respecting finish of init(), and I cant pack the indexes into WAR 
 because breaks Amazons max war size of 1/2 GB

Again, which init() are you talking about?

 Neither tar nor gzip take very much of anything: they are both 
 block-oriented. What procedure were you using to decompress the 
 tarballs? Decompressing the entire tarball and then tearing it
 apart is a mistake: you should chain the processes together so
 you read from the tarball and write individual, uncompressed
 files to the disk.
 
 With the java solution I was using
 
 |import  org.rauschig.jarchivelib.Archiver; import
 org.rauschig.jarchivelib.ArchiverFactory; . File
 indexDirFile=  new  File(indexDirParent).getAbsoluteFile(); 
 indexDirFile.mkdirs(); Archiver  archiver=
 ArchiverFactory.createArchiver(largeFile); 
 archiver.extract(largeFile,  indexDirFile);
 
 which is a library around Apache Compress, and that did create a 
 temporary tar file

You want to manage the streams yourself: hook a gzip reader up to a
tar reader and then read files from the tar reader:

GzipInputStream gzin = new GzipInputStream(tgzFile);
TarInputStream tin = new TarInputStream(gzin);

InputStream fin;

while(fin = tin.getNextFile())
   copy(fin, new File(localFilename));

That's oversimplified, but essentially what you want to do. There is
no need to completely expand the gzip archive before reading files out
of it.

 But maybe if using linux commands directly I wont hit the problem.
 I think using .ebextensions is now my best chance of getting
 something working.

Okay. I have no idea what those are so I can't comment.

If you have to download the indexes from elsewhere, you might want to
download a compressed file since expanding the compressed file will
probably be faster than downloading an uncompressed version of it.

 There is another option: stick the master index on an EBS store
 and mount the EBS store on the target machine. IIRC, EBS volumes
 can't be shared (which is a big pain IMO) so you can't mount that
 disk on all of your Lucene servers... you might have to mount the
 EBS store, copy the indexes, and then unmount the store. You'd
 only have to do this once each time you wanted to launch an
 additional instance or update the index.
 
 But the whole point of Autoscaled EB deployments, is Amazon 
 automatically starts additional servers if load gets heavy and 
 terminates them if underused. I dont have to consciously make
 those decisions or be around, very useful if (as I suspect) Im
 going to have busy and quiet times during each 24 hour period.
 Maybe I could have 4 EBS stores loaded (default max no of servers
 is 4) ready and then when server starts have some code in my init()
 method  to mount the next available(not mounted) EBS volume and use
 it. But I think this does been paying for four EBS stores all the
 time , and I dont know how to code for this because usually AFAIK
 the volumes have to be assigned to an EC2 instance before the
 instance can mount them.

Correct, you'd have to associate the EBS volume with the instance,
then mount on the instance. If I were doing it, I'd do it with a
single EBS instance instead of 4 because you only need access one-time
to copy the files.

 Or, you could look into Solr which I believe understands
 clustering. Then, you load the index onto the cluster and do
 whatever you want with it.
 
 I dont think Solr clustering would with EB autoscaling instead I
 would have to work directly with EC2 and forgo all the advantages
 of EB autoscaling, also I already have my code written and working
 I have no desire (or time)  

Re: [ANN] Apache Tomcat 8.0.9 (stable) available

2014-07-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Emmanual,

On 7/2/14, 5:26 PM, Emmanuel Bourg wrote:
 I'm also pleased to announce that Tomcat 8.0.9 is now available
 for Debian 7 (Wheezy) through the backport repository [1].

Nice job!

It's nice to see Debian working to shed that image of always being 3
years behind ;)

Seriously, though, it's nice to get a recent version of Tomcat
supported in Debian. My team uses Debian for all production
deployments (though not for Java/Tomcat packages), so we're fans.

Keep up the good work!

Thanks,
- -chris

 
 The repository has to be declared in /etc/apt/sources.list by
 adding this line:
 
 deb http://http.debian.net/debian wheezy-backports main
 
 The package can then be installed with:
 
 apt-get update apt-get install tomcat8
 
 For Ubuntu users the package is also available for Utopic Unicorn
 [2] (to be released this fall).
 
 Emmanuel Bourg
 
 [1] http://backports.debian.org [2]
 http://packages.ubuntu.com/utopic/tomcat8
 
 
 Le 26/06/2014 09:00, Mark Thomas a écrit :
 The Apache Tomcat team announces the immediate availability of
 Apache Tomcat 8.0.9, the first stable release of the 8.0.x
 series.
 
 Apache Tomcat 8 is an open source software implementation of the
 Java Servlet, JavaServer Pages, Java Unified Expression Language
 and Java WebSocket technologies.
 
 Apache Tomcat 8 is aligned with Java EE 7. In addition to
 supporting updated versions of the Java EE specifications, Tomcat
 8 includes a number of improvements compared to Tomcat 7. The
 notable changes include:
 
 - Support for Java Servlet 3.1, JavaServer Pages 2.3, Java
 Unified Expression Language 3.0 and Java WebSocket 1.0.
 
 - The default connector implementation is now the Java
 non-blocking implementation (NIO) for both HTTP and AJP.
 
 - A new resources implementation that replaces Aliases,
 VirtualLoader, VirtualDirContext, JAR resources and external
 repositories with a single, consistent approach for configuring
 additional web application resources. The new resources
 implementation can also be used to implement overlays (using a
 master WAR as the basis for multiple web applications that each
 have their own customizations).
 
 
 Apache Tomcat 8.0.9 includes numerous fixes for issues
 identified in 8.0.8 as well as a number of other enhancements and
 changes. The notable changes since 8.0.8 include:
 
 - Start to move towards RFC6265 for cookie handling
 
 - Better error handling when the error occurs after the response
 has been committed
 
 - Various Jasper improvements to make it easier for other
 containers (e.g. Jetty) to consume
 
 
 Please refer to the change log for the complete list of changes: 
 http://tomcat.apache.org/tomcat-8.0-doc/changelog.html
 
 Note: This version has 4 zip binaries: a generic one and three 
 bundled with Tomcat native binaries for Windows operating
 systems running on different CPU architectures.
 
 Downloads: http://tomcat.apache.org/download-80.cgi
 
 Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: 
 http://tomcat.apache.org/migration.html
 
 Enjoy!
 
 - The Apache Tomcat team
 
 
 -

 
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTtXFFAAoJEBzwKT+lPKRY6OIP/io9mmIXqda8DUa5agVjuaur
Z26LsJnMQYK+Chc8EGWk1+PUfSQnDAr3mPhudy6vP7xBBeEoXuqBEnZ2AACeEdLG
Zhi8z7YRw5srU0oI+G41hru19bRBcwuElDxi8OuIJI21vPZ9LQS5CHHNYzj35hIV
ofQX/Ka53p/Gt71vkPyiwrGb1jn0mh/f3Z8D5QU7njjm2q49XhfpKTUVEpVJi6FU
IxdreUS0jM7658iJ429asEDVR04DtnUnp6er99bcWasdu8JEul+iK7NhDmotvjf+
oMCWDUdrG+SL5bkXTANnEfKCBzKnUyzH2mwCt9kpvoUIZUj51Oxah8/Sj6Q0s3IM
SusPRrZTSeKUdilk5iEfhjHx0lAE6o6e8AdzuniZGZ8R3gWTqfX83mP7BPRuc2FV
aFiOrEWe19NCLHqWd7BRXS0eKwwsg8v3Dq4zzWiZcZhDmOp1W6Pf04IdsuhJVo6K
GQCAAar49oGCY8iamalFYtZcRxzWaZYuDIAa+pELkmSDAIpZ/4G8aRRiqed2f4jp
f37aI3aLKzy98uL4oIoMjGd+59k/Y0UNIFOOEYsrgIQ5Ve1Zt+JrQd7+jYvuq/WE
a86nY9YibCE8DrmNkd/stMfzq2WQpXPKgegvujPCyqB8okTSRjQ1q9Iqd9XR4rDQ
Lx+LPY8R1H6AmNjHxpIq
=jiUw
-END PGP SIGNATURE-

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



Re: [somewhat OT] Apache Tomcat7 service start randomly after the installation of McAfee antivirus.

2014-07-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 7/2/14, 3:33 AM, André Warnier wrote:
 Blachon, Philippe wrote:
 Good morning,
 
 We have 4 identical servers with a scheduled task running every
 night on each of them. This task Stop Tomcat - Update some data
 - Start Tomcat. This worked fine for months. We have installed a
 new antivirus McAfee 3 weeks ago. Now the Tomcat7 service starts
 randomly. At least 1 of the 4 server needs a manual start of the
 Tomcat7 service every morning.
 
 Do you know if there is specifics problems between Tomcat and Mc
 Afee ? We have already tried to exclude Tomcat.exe from McAfee
 scanning. Is there other thing we could exclude without
 compromising the security ?
 
 Configuration: Windows server 2008 R2 Standard - SP1 Apache
 Tomcat 7.0.29 Server McAffee Agent 4.8.0.1500 Mcafee VirusScan
 Enterprise 8.8.04001
 
 Thanks, have a nice day, Philippe Blachon.
 
 
 Not a direct answer to your question, but maybe a bit of lateral
 and logical thinking here :
 
 Why would one run a virus scanner permanently on a Tomcat server ? 
 And why run it on most of the disk space, as opposed to just the
 few directories where some client /might/ upload external files ? 
 Do the applications even allow clients to put files on that server
 ?

As someone who has to meet certain government-mandated regulations, I
can commiserate with the OP: sometimes you have to do stupid crap just
so somebody doesn't say why aren't you following industry-standard
guidelines?

The good news is that use anti-virus and anti-malware can be
interpreted in ... liberal ways.

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

iQIcBAEBCAAGBQJTtXHnAAoJEBzwKT+lPKRYsxkP/1OILpKwugR9wSxJ27RJLQS/
GLffRY3tCTSUZi8fgFkPoNslV1CQbDbpu35vU7m4H8Il4JYzJeJS95Tap75B+4OZ
jgngjcg9lIqa8zIZjOEa7Ke3dYPghaIVMUSrq+KNzg7BaxUTdhHNYcvjcy3063rW
YmwVH/euhcNZ3FFHPjLGtFvm0/BNXQFkVacjz7EGkBxTpW7yIoDdsMyyXx5jeMCz
CNjt4tOKm5rheFpfZKCWNyHXNBJpYN9fSkNybJb9171jjM6IhyAoS1fCZHWYMGu7
z0IWZd5OuFUtxD5hXn5sARDzces3EYN3+AtSkgE2OfXGBq2Po8TpaHnfc9Q7ZF1p
YCkuUG9MlSgY40M1KVrrlqiNfUBnsKpe6zkjpfxE8rI0PWuGOM2Oe3g6m+BWznJf
Lal5iJKiEm8ZOOualYBz4DQjb1CxYJPJTKxe3+QZ6tSov+SIikl5MCkUGkfYU7Yo
Ixq9QJoqzFWvGZRQJEVdnDPvY6O0onsCGYzLJELTPkpkkF3CEMyNU5GIhvZrMTdo
glrNnncBLbLr9e0NAd0oK2Mr0ZH8264TOoDctyMCHguBvwosK3QKco4+4SY7ITlH
wEHjBizwUX/Kyw5NT8wgTEYWMGmeeqcb9xXqKfL0AmOLW8XdonhRIQGLUA9hr/zE
L0T/NVh2GwFgORZpFDU8
=nGv9
-END PGP SIGNATURE-

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



Issue with spring when migrating from 7.0.50 to 7.0.52-53-54

2014-07-03 Thread Xavier Outhier
Hi,

we have an application that is running under Tomcat. We are trying to upgrade 
to latest version 7.0.54 from 7.0.39.
As 7.0.54 lead to some errors, we tried to find out which version broke the 
application. The result is that the issue appears with 7.0.52 and is not 
present until 7.0.50.

The exception that we can see is:
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 
'org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor#0'
 defined in file [xyz]: Initialization of bean failed; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'entityManagerFactory' defined in file [xyz]: Invocation of init 
method failed; nested exception is java.lang.IncompatibleClassChangeError: 
Class org.eclipse.persistence.jpa.PersistenceProvider does not implement the 
requested interface javax.persistence.spi.PersistenceProvider
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527)
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
    at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
    at 
org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:710)
    at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:410)
    at 
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276)
    at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
    at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
    at xyz(xyz1.java:41)
    at xyz (xyz2.java:94)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'entityManagerFactory' defined in file [xyz]: 
Invocation of init method failed; nested exception is 
java.lang.IncompatibleClassChangeError: Class 
org.eclipse.persistence.jpa.PersistenceProvider does not implement the 
requested interface javax.persistence.spi.PersistenceProvider
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
    at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
    at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
    at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:398)
    at 
org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:275)
    at 
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.detectPersistenceExceptionTranslators(PersistenceExceptionTranslationInterceptor.java:139)
    at 
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.init(PersistenceExceptionTranslationInterceptor.java:79)
    at 
org.springframework.dao.annotation.PersistenceExceptionTranslationAdvisor.init(PersistenceExceptionTranslationAdvisor.java:70)
    at 
org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor.setBeanFactory(PersistenceExceptionTranslationPostProcessor.java:99)
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeAwareMethods(AbstractAutowireCapableBeanFactory.java:1439)
    at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1408)
    at 

Re: Issue with spring when migrating from 7.0.50 to 7.0.52-53-54

2014-07-03 Thread Filip Hanik
These errors may happen when you have two libraries that both contain the
class javax.persistence.spi.PersistenceProvider
search the libraries (*.jar) in both tomcat and your WAR file, and see if
there are multiple instances of the above named class


On Thu, Jul 3, 2014 at 9:28 AM, Xavier Outhier xouth...@yahoo.fr wrote:

 Hi,

 we have an application that is running under Tomcat. We are trying to
 upgrade to latest version 7.0.54 from 7.0.39.
 As 7.0.54 lead to some errors, we tried to find out which version broke
 the application. The result is that the issue appears with 7.0.52 and is
 not present until 7.0.50.

 The exception that we can see is:
 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name
 'org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor#0'
 defined in file [xyz]: Initialization of bean failed; nested exception is
 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'entityManagerFactory' defined in file [xyz]: Invocation of
 init method failed; nested exception is
 java.lang.IncompatibleClassChangeError: Class
 org.eclipse.persistence.jpa.PersistenceProvider does not implement the
 requested interface javax.persistence.spi.PersistenceProvider
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
 at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
 at
 org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:710)
 at
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:410)
 at
 org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276)
 at
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
 at
 org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
 at xyz(xyz1.java:41)
 at xyz (xyz2.java:94)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)
 Caused by: org.springframework.beans.factory.BeanCreationException: Error
 creating bean with name 'entityManagerFactory' defined in file [xyz]:
 Invocation of init method failed; nested exception is
 java.lang.IncompatibleClassChangeError: Class
 org.eclipse.persistence.jpa.PersistenceProvider does not implement the
 requested interface javax.persistence.spi.PersistenceProvider
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
 at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
 at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
 at
 org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType(DefaultListableBeanFactory.java:398)
 at
 org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors(BeanFactoryUtils.java:275)
 at
 org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.detectPersistenceExceptionTranslators(PersistenceExceptionTranslationInterceptor.java:139)
 at
 org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.init(PersistenceExceptionTranslationInterceptor.java:79)
 at
 org.springframework.dao.annotation.PersistenceExceptionTranslationAdvisor.init(PersistenceExceptionTranslationAdvisor.java:70)
 at
 org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor.setBeanFactory(PersistenceExceptionTranslationPostProcessor.java:99)
 

RE: Error in DBCP Connection Pool with tomcat 6.x

2014-07-03 Thread Propes, Barry L
Good to hear.

-Original Message-
From: Vijendra Pachoriya [mailto:vijendra.pachor...@indegene.com] 
Sent: Thursday, July 03, 2014 8:22 AM
To: Tomcat Users List
Subject: RE: Error in DBCP Connection Pool with tomcat 6.x

Thanks everyone !!

Managed to solve the issue. It seems the wait time out for db was less than 
that of configured in tomcat.

Which was leading to close the connection before tomcat does it.
 
Regards,
Vijendra


-Original Message-
From: Phil Steitz [mailto:phil.ste...@gmail.com]
Sent: 02 July 2014 22:33
To: Tomcat Users List
Subject: Re: Error in DBCP Connection Pool with tomcat 6.x

On 7/1/14, 10:48 PM, Vijendra Pachoriya wrote:
 Hi Filip,

 This error comes at some point of time on production, when the server is on 
 load.

 I am using hibernate and not closing any connection manually, its all managed 
 by hibernate and tomcat dbcp connection pool.

Two additional things to check:

1) Check logs to see if abandoned connections are being removed.  If your code 
is closing all connections, you should not need this to be enabled.
2) Make sure that there is no sharing across threads of the Hibernate objects.

Phil

 For me it seems like DBCP is trying to close the connection which is already 
 closed by the database server.

 Please refer below related links.

 https://issues.apache.org/jira/browse/DBCP-329

 http://markmail.org/message/c2gx2xuzum4pv743#query:+page:1+mid:ncvixx4
 ewe7pho2x+state:results


 Regards,
 Vijendra

 -Original Message-
 From: Filip Hanik [mailto:fi...@hanik.com]
 Sent: 01 July 2014 21:06
 To: Tomcat Users List
 Subject: Re: Error in DBCP Connection Pool with tomcat 6.x

 Looks like your code already called java.sql.Connection.close() and 
 then attempts to use the connection again

 Filip



 On Tue, Jul 1, 2014 at 8:09 AM, Propes, Barry L 
 barry.l.pro...@citi.com
 wrote:


 -Original Message-
 From: Vijendra Pachoriya [mailto:vijendra.pachor...@indegene.com]
 Sent: Tuesday, July 01, 2014 2:31 AM
 To: users@tomcat.apache.org
 Cc: Alok Roy
 Subject: Error in DBCP Connection Pool with tomcat 6.x

 Hi Tomcat Team,

 Please help me out in solving below error.

 Below is the details :

 Configuration in my
 context.xml


 Resource name=jdbc/ABC
 auth=Container
 type=javax.sql.DataSource
 maxActive=50
 maxIdle=10
 maxWait=1
 username=ABC
 password=ABC
 removeAbandoned=true
 logAbandoned=true
 testOnBorrow=true
 testWhileIdle=true
 timeBetweenEvictionRunsMillis=3
 validationQuery=SELECT 1 FROM dual
 driverClassName=oracle.jdbc.driver.OracleDriver
 url=jdbc:oracle:thin:@MY_DB /


 ==Error Message 
 

 at
 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
 at
 org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
 at
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
 at java.lang.Thread.run(Thread.java:679)
 Caused by: org.springframework.transaction.TransactionSystemException:
 Could not roll back JPA transaction; nested exception is
 javax.persistence.PersistenceException: unexpected error when rollbacking
 at
 org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:486)
 at
 org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:800)
 at
 org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:777)
 at
 org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:339)
 at
 org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
 at
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
 at
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at sun.proxy.$Proxy185.selectPharmaUser(Unknown Source)
 at
 com.aptilon.axcelrx.server.service.impl.AuthenticationServiceImpl.login(AuthenticationServiceImpl.java:170)
 at
 com.aptilon.axcelrx.server.ws.endpoint.AuthenticationEndpoint.login_aroundBody0(AuthenticationEndpoint.java:110)
 ... 45 more
 Caused by: javax.persistence.PersistenceException: unexpected error 
 when rollbacking
 at
 org.hibernate.ejb.TransactionImpl.rollback(TransactionImpl.java:88)
 at
 org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:482)
 ... 54 more
 Caused by: org.hibernate.exception.GenericJDBCException: Cannot 
 release connection
 at

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hello!

Using NIO (with channelSendOptions=4, i.e., synchronous), with lightly
load, my tests pass 100%. But, on heavy load, not all sessions are
replicated on time, and I have about 20% of errors. If I increase
maxThreads to 400, I have about 15% of errors.

More information:
* I am not performing parallel requests with same session
* my cluster has 4 nodes (all in one machine - for test purpose only)
* Java 7 64 bits, Tomcat 7.0.52, windows 7 64 bits
* using default NIO configuration, but with maxThreads=400
* VM options:
-Xms512M   - on real environment this value is 1024
-Xmx512M  - on real environment this value is 1024
-XX:NewSize=450M
-XX:MaxNewSize=450M
-XX:PermSize=128M
-XX:MaxPermSize=245M
-XX:SurvivorRatio=8
-XX:TargetSurvivorRatio=90
-XX:MaxTenuringThreshold=15
-XX:+UseBiasedLocking
-XX:CMSInitiatingOccupancyFraction=60
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+UseParNewGC
-XX:+DisableExplicitGC
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:%CATALINA_BASE%/logs/tomcat-gc.log

Moreover, I'm trying to attach the logs again.

Thanks
João


cluster.rar
Description: application/rar

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

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
cluster.log - http://pastebin.com/c98WhnmG


2014-07-03 13:04 GMT-03:00 João Sávio joaosa...@gmail.com:

 Hello!

 Using NIO (with channelSendOptions=4, i.e., synchronous), with lightly
 load, my tests pass 100%. But, on heavy load, not all sessions are
 replicated on time, and I have about 20% of errors. If I increase
 maxThreads to 400, I have about 15% of errors.

 More information:
 * I am not performing parallel requests with same session
 * my cluster has 4 nodes (all in one machine - for test purpose only)
 * Java 7 64 bits, Tomcat 7.0.52, windows 7 64 bits
 * using default NIO configuration, but with maxThreads=400
 * VM options:
 -Xms512M   - on real environment this value is 1024
 -Xmx512M  - on real environment this value is 1024
 -XX:NewSize=450M
 -XX:MaxNewSize=450M
 -XX:PermSize=128M
 -XX:MaxPermSize=245M
 -XX:SurvivorRatio=8
 -XX:TargetSurvivorRatio=90
 -XX:MaxTenuringThreshold=15
 -XX:+UseBiasedLocking
 -XX:CMSInitiatingOccupancyFraction=60
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:+CMSClassUnloadingEnabled
 -XX:+UseConcMarkSweepGC
 -XX:+CMSIncrementalMode
 -XX:+UseParNewGC
 -XX:+DisableExplicitGC
 -XX:+PrintGCDateStamps
 -XX:+PrintGCDetails
 -Xloggc:%CATALINA_BASE%/logs/tomcat-gc.log

 Moreover, I'm trying to attach the logs again.

 Thanks
 João




-- 
http://joaosavio.wordpress.com


cluster.rar
Description: application/rar

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

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Daniel Mikusa
On Thu, Jul 3, 2014 at 12:04 PM, João Sávio joaosa...@gmail.com wrote:

 Hello!

 Using NIO (with channelSendOptions=4, i.e., synchronous), with lightly
 load, my tests pass 100%. But, on heavy load, not all sessions are
 replicated on time,


Define on time.


 and I have about 20% of errors.


Can you explain the errors more?  Stack trace?


 If I increase maxThreads to 400, I have about 15% of errors.

 More information:
 * I am not performing parallel requests with same session
 * my cluster has 4 nodes (all in one machine - for test purpose only)
 * Java 7 64 bits, Tomcat 7.0.52, windows 7 64 bits
 * using default NIO configuration, but with maxThreads=400
 * VM options:
 -Xms512M   - on real environment this value is 1024
 -Xmx512M  - on real environment this value is 1024
 -XX:NewSize=450M
 -XX:MaxNewSize=450M
 -XX:PermSize=128M
 -XX:MaxPermSize=245M
 -XX:SurvivorRatio=8
 -XX:TargetSurvivorRatio=90
 -XX:MaxTenuringThreshold=15
 -XX:+UseBiasedLocking
 -XX:CMSInitiatingOccupancyFraction=60
 -XX:+UseCMSInitiatingOccupancyOnly
 -XX:+CMSClassUnloadingEnabled
 -XX:+UseConcMarkSweepGC
 -XX:+CMSIncrementalMode
 -XX:+UseParNewGC


You have quite a few JVM settings configured here.  No criticism to this, I
assume that you've not copy and pasted these from the internet and have
thoroughly tested each one.  I'm just mentioning this because I often see
people do this and it usually backfires.  Just curious if you've tried
things without all of these customizations.  Perhaps with just some basics
like -Xms, -Xmx and gc logging?


 -XX:+DisableExplicitGC
 -XX:+PrintGCDateStamps
 -XX:+PrintGCDetails
 -Xloggc:%CATALINA_BASE%/logs/tomcat-gc.log

 Moreover, I'm trying to attach the logs again.


The list doesn't like attachments.  On some rare occasions it'll accept
them, but it's generally better to inline the logs.  Also some people,
myself included, are paranoid and don't open attachments from people they
do not know.

Dan


Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Mark Eggers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/3/2014 9:12 AM, João Sávio wrote:
 cluster.log - http://pastebin.com/c98WhnmG
 
 
 2014-07-03 13:04 GMT-03:00 João Sávio joaosa...@gmail.com:
 
 Hello!
 
 Using NIO (with channelSendOptions=4, i.e., synchronous), with
 lightly load, my tests pass 100%. But, on heavy load, not all
 sessions are replicated on time, and I have about 20% of errors.
 If I increase maxThreads to 400, I have about 15% of errors.
 
 More information: * I am not performing parallel requests with
 same session * my cluster has 4 nodes (all in one machine - for
 test purpose only) * Java 7 64 bits, Tomcat 7.0.52, windows 7 64
 bits * using default NIO configuration, but with maxThreads=400 *
 VM options: -Xms512M   - on real environment this value is 1024 
 -Xmx512M  - on real environment this value is 1024 
 -XX:NewSize=450M -XX:MaxNewSize=450M -XX:PermSize=128M 
 -XX:MaxPermSize=245M -XX:SurvivorRatio=8 
 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 
 -XX:+UseBiasedLocking -XX:CMSInitiatingOccupancyFraction=60 
 -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled 
 -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+UseParNewGC 
 -XX:+DisableExplicitGC -XX:+PrintGCDateStamps 
 -XX:+PrintGCDetails -Xloggc:%CATALINA_BASE%/logs/tomcat-gc.log
 
 Moreover, I'm trying to attach the logs again.
 
 Thanks João

João,

I took a look at the log. This is the BIO attempt and you do run out
of threads. See the following:

Jul 03, 2014 11:41:21 AM
org.apache.catalina.tribes.transport.bio.BioReceiver listen
WARNING: All BIO server replication threads are busy, unable to handle
more requests until a thread is freed up.

What's the load like on the box when you're running the tests that you
get errors on?

As Dan asks in his message:

What is on time?
What are the errors? Test result errors?

How big are are the sessions that you're trying to replicate?

My guess is that something else is going on, since the following log
entry doesn't show much in the way of cluster traffic.

INFO: ThroughputInterceptor Report[
Tx Msg:1 messages
Sent:0.00 MB (total)
Sent:0.00 MB (application)
Time:0.01 seconds
Tx Speed:0.04 MB/sec (total)
TxSpeed:0.04 MB/sec (application)
Error Msg:0
Rx Msg:13 messages
Rx Speed:0.00 MB/sec (since 1st msg)
Received:0.00 MB]

It would also be interesting to see the logs when you use the NIO
connector. According to the documentation:

It is preferred to use the non blocking receiver to be able to grow
your cluster without running into thread starvation.

Also from the documentation:

Usually the rule is to use 1 thread per node in the cluster for small
clusters, and then depending on your message frequency and your
hardware, you'll find an optimal number of threads peak out at a
certain number.

We might need a little more background on your application and your
test environment to figure out why clustering is not behaving for you.

. . . just my two cents
/mde/

PS - you have some errors in your server.xml (see the log). While they
won't impact this problem, it might be a good idea to address them.

/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTtY28AAoJEEFGbsYNeTwtbk4H/1ehs00fmOLGfpcDxKkbfJJc
B2T3FEYmW2scV/W3Z0+z4uhBgVwRqPHgEZHotdRFhkadymCKz0d5RjjEgnTMv5vH
eP1u35NjmtteeLg+EcZU9XP1HOR+oxcx9fFic9NULtUb1lQOd9pIV9SWO82vFSI5
0ERzCxMr/ysiOZHPXPwl6SCe9TWGwYAWJh1QrH+3tqaD+EV7mYdZk7P/MOSWnSxn
JzLRkO+nKPXLYv6NQiSzjCoyURIxv8+fIw3vIblx03vfhyKFlb/KR9r8ZfhlSiJ0
i9fKzpRXmCVIHchWCDWKV89l6KzOyIYPVv3LlprGyLtCTbaBqvBQu5iFOhbHHiw=
=jgsE
-END PGP SIGNATURE-

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



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hello

Some points below:

** What is on time?*
In my application, a group of users should always hit the same node after
the first request. So, in first request each group of users will receive an
specific cookie, and LB will perform the load balancing based on this
cookie. In first request, a user can hit any node, but from the second, he
or she should hit the same node.

** What are the errors? Test result errors?*
For this test, I simplified the code of my application:
- first request: store one object in session
- second request: verify if the object is in session. If it's not - ERROR

** How big are are the sessions that you're trying to replicate?*
- I'm using Spring MVC, and I have 3 additional objects in session. They
are not big (15 attributes each one)

** What's the load like on the box when you're running the tests that
you get errors on?*
- I've experiencing this issue on BIO even without load

** It is preferred to use the non blocking receiver to be able to grow your
cluster without running into thread starvation.*
- That's why I've tried NIO first, but I'd like to see if BIO solve my
issue and if using BIO my system doesn't get too slow.


Now, I'll try to run my tests using NIO, default VM configuration and FINER
logs.

Thanks a lot
João


2014-07-03 14:07 GMT-03:00 Mark Eggers its_toas...@yahoo.com.invalid:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/3/2014 9:12 AM, João Sávio wrote:
  cluster.log - http://pastebin.com/c98WhnmG
 
 
  2014-07-03 13:04 GMT-03:00 João Sávio joaosa...@gmail.com:
 
  Hello!
 
  Using NIO (with channelSendOptions=4, i.e., synchronous), with
  lightly load, my tests pass 100%. But, on heavy load, not all
  sessions are replicated on time, and I have about 20% of errors.
  If I increase maxThreads to 400, I have about 15% of errors.
 
  More information: * I am not performing parallel requests with
  same session * my cluster has 4 nodes (all in one machine - for
  test purpose only) * Java 7 64 bits, Tomcat 7.0.52, windows 7 64
  bits * using default NIO configuration, but with maxThreads=400 *
  VM options: -Xms512M   - on real environment this value is 1024
  -Xmx512M  - on real environment this value is 1024
  -XX:NewSize=450M -XX:MaxNewSize=450M -XX:PermSize=128M
  -XX:MaxPermSize=245M -XX:SurvivorRatio=8
  -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15
  -XX:+UseBiasedLocking -XX:CMSInitiatingOccupancyFraction=60
  -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled
  -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+UseParNewGC
  -XX:+DisableExplicitGC -XX:+PrintGCDateStamps
  -XX:+PrintGCDetails -Xloggc:%CATALINA_BASE%/logs/tomcat-gc.log
 
  Moreover, I'm trying to attach the logs again.
 
  Thanks João

 João,

 I took a look at the log. This is the BIO attempt and you do run out
 of threads. See the following:

 Jul 03, 2014 11:41:21 AM
 org.apache.catalina.tribes.transport.bio.BioReceiver listen
 WARNING: All BIO server replication threads are busy, unable to handle
 more requests until a thread is freed up.

 What's the load like on the box when you're running the tests that you
 get errors on?

 As Dan asks in his message:

 What is on time?
 What are the errors? Test result errors?

 How big are are the sessions that you're trying to replicate?

 My guess is that something else is going on, since the following log
 entry doesn't show much in the way of cluster traffic.

 INFO: ThroughputInterceptor Report[
 Tx Msg:1 messages
 Sent:0.00 MB (total)
 Sent:0.00 MB (application)
 Time:0.01 seconds
 Tx Speed:0.04 MB/sec (total)
 TxSpeed:0.04 MB/sec (application)
 Error Msg:0
 Rx Msg:13 messages
 Rx Speed:0.00 MB/sec (since 1st msg)
 Received:0.00 MB]

 It would also be interesting to see the logs when you use the NIO
 connector. According to the documentation:

 It is preferred to use the non blocking receiver to be able to grow
 your cluster without running into thread starvation.

 Also from the documentation:

 Usually the rule is to use 1 thread per node in the cluster for small
 clusters, and then depending on your message frequency and your
 hardware, you'll find an optimal number of threads peak out at a
 certain number.

 We might need a little more background on your application and your
 test environment to figure out why clustering is not behaving for you.

 . . . just my two cents
 /mde/

 PS - you have some errors in your server.xml (see the log). While they
 won't impact this problem, it might be a good idea to address them.

 /mde/
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (MingW32)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJTtY28AAoJEEFGbsYNeTwtbk4H/1ehs00fmOLGfpcDxKkbfJJc
 B2T3FEYmW2scV/W3Z0+z4uhBgVwRqPHgEZHotdRFhkadymCKz0d5RjjEgnTMv5vH
 eP1u35NjmtteeLg+EcZU9XP1HOR+oxcx9fFic9NULtUb1lQOd9pIV9SWO82vFSI5
 0ERzCxMr/ysiOZHPXPwl6SCe9TWGwYAWJh1QrH+3tqaD+EV7mYdZk7P/MOSWnSxn
 

Re: Error in DBCP Connection Pool with tomcat 6.x

2014-07-03 Thread Aniket Bhoi
On Thu, Jul 3, 2014 at 9:11 PM, Propes, Barry L barry.l.pro...@citi.com
wrote:

 Good to hear.

 -Original Message-
 From: Vijendra Pachoriya [mailto:vijendra.pachor...@indegene.com]
 Sent: Thursday, July 03, 2014 8:22 AM
 To: Tomcat Users List
 Subject: RE: Error in DBCP Connection Pool with tomcat 6.x

 Thanks everyone !!

 Managed to solve the issue. It seems the wait time out for db was less
 than that of configured in tomcat.

 Which was leading to close the connection before tomcat does it.

 Regards,
 Vijendra


 -Original Message-
 From: Phil Steitz [mailto:phil.ste...@gmail.com]
 Sent: 02 July 2014 22:33
 To: Tomcat Users List
 Subject: Re: Error in DBCP Connection Pool with tomcat 6.x

 On 7/1/14, 10:48 PM, Vijendra Pachoriya wrote:
  Hi Filip,
 
  This error comes at some point of time on production, when the server is
 on load.
 
  I am using hibernate and not closing any connection manually, its all
 managed by hibernate and tomcat dbcp connection pool.

 Two additional things to check:

 1) Check logs to see if abandoned connections are being removed.  If your
 code is closing all connections, you should not need this to be enabled.
 2) Make sure that there is no sharing across threads of the Hibernate
 objects.

 Phil
 
  For me it seems like DBCP is trying to close the connection which is
 already closed by the database server.
 
  Please refer below related links.
 
  https://issues.apache.org/jira/browse/DBCP-329
 
  http://markmail.org/message/c2gx2xuzum4pv743#query:+page:1+mid:ncvixx4
  ewe7pho2x+state:results
 
 
  Regards,
  Vijendra
 
  -Original Message-
  From: Filip Hanik [mailto:fi...@hanik.com]
  Sent: 01 July 2014 21:06
  To: Tomcat Users List
  Subject: Re: Error in DBCP Connection Pool with tomcat 6.x
 
  Looks like your code already called java.sql.Connection.close() and
  then attempts to use the connection again
 
  Filip
 
 
 
  On Tue, Jul 1, 2014 at 8:09 AM, Propes, Barry L
  barry.l.pro...@citi.com
  wrote:
 
 
  -Original Message-
  From: Vijendra Pachoriya [mailto:vijendra.pachor...@indegene.com]
  Sent: Tuesday, July 01, 2014 2:31 AM
  To: users@tomcat.apache.org
  Cc: Alok Roy
  Subject: Error in DBCP Connection Pool with tomcat 6.x
 
  Hi Tomcat Team,
 
  Please help me out in solving below error.
 
  Below is the details :
 
  Configuration in my
  context.xml
 
 
  Resource name=jdbc/ABC
  auth=Container
  type=javax.sql.DataSource
  maxActive=50
  maxIdle=10
  maxWait=1
  username=ABC
  password=ABC
  removeAbandoned=true
  logAbandoned=true
  testOnBorrow=true
  testWhileIdle=true
  timeBetweenEvictionRunsMillis=3
  validationQuery=SELECT 1 FROM dual
  driverClassName=oracle.jdbc.driver.OracleDriver
  url=jdbc:oracle:thin:@MY_DB /
 
 
  ==Error Message
  
 
  at
 
 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
  at
 
 org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
  at
 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
  at java.lang.Thread.run(Thread.java:679)
  Caused by: org.springframework.transaction.TransactionSystemException:
  Could not roll back JPA transaction; nested exception is
  javax.persistence.PersistenceException: unexpected error when
 rollbacking
  at
 
 org.springframework.orm.jpa.JpaTransactionManager.doRollback(JpaTransactionManager.java:486)
  at
 
 org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:800)
  at
 
 org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:777)
  at
 
 org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:339)
  at
 
 org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
  at
 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
  at
 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
  at sun.proxy.$Proxy185.selectPharmaUser(Unknown Source)
  at
 
 com.aptilon.axcelrx.server.service.impl.AuthenticationServiceImpl.login(AuthenticationServiceImpl.java:170)
  at
 
 com.aptilon.axcelrx.server.ws.endpoint.AuthenticationEndpoint.login_aroundBody0(AuthenticationEndpoint.java:110)
  ... 45 more
  Caused by: javax.persistence.PersistenceException: unexpected error
  when rollbacking
  at
  org.hibernate.ejb.TransactionImpl.rollback(TransactionImpl.java:88)
  

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Mark Eggers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

João,

This list has a convention of posting either inline or at the end of
the message you're replying to.

See here for mailing list notes:

http://tomcat.apache.org/lists.html#tomcat-users

On 7/3/2014 10:24 AM, João Sávio wrote:
 Hello
 
 Some points below:
 
 ** What is on time?* In my application, a group of users should 
 always hit the same node after the first request. So, in first 
 request each group of users will receive an specific cookie, and
 LB will perform the load balancing based on this cookie. In first 
 request, a user can hit any node, but from the second, he or she 
 should hit the same node.

Hmm, so 'on time' really means that subsequent requests should hit the
same server.

If you're using sessions, Tomcat has an attribute on the Engine
element called jvmRoute. So depending on your load balancer (and if
you use AJP), you can use Tomcat and AJP to route traffic. In that
case, there's no need to write a special cookie.

At any rate, this doesn't sound like a clustering error per se.

 
 ** What are the errors? Test result errors?* For this test, I 
 simplified the code of my application: - first request: store one 
 object in session - second request: verify if the object is in 
 session. If it's not - ERROR
 

So looking at the information from 'on time', the scenario should be:

1. first request, pick a random server and store a session object
2. second request, pick the SAME server and ask for the session object

Again, I'm not seeing where this is a clustering issue per se.

 ** How big are are the sessions that you're trying to replicate?*
 - I'm using Spring MVC, and I have 3 additional objects in
 session. They are not big (15 attributes each one)
 

And all attributes are serializable? The objects are also marked as
serializable?

 ** What's the load like on the box when you're running the tests 
 that you get errors on?* - I've experiencing this issue on BIO
 even without load
 

I may have not phrased my question carefully. What is the CPU and
memory situation on your test box while running the 4 Tomcat servers?

I know you've trimmed down your Xms and Xmx (presumably to fit in your
test environment), but in combination with your other JVM parameters
could this be causing some issues?

I would follow Dan's recommendation of maybe just setting Xms, Xmx, GC
logging to see what happens. Ah, I see you're going to do that below.

 ** It is preferred to use the non blocking receiver to be able to 
 grow your cluster without running into thread starvation.* -
 That's why I've tried NIO first, but I'd like to see if BIO solve
 my issue and if using BIO my system doesn't get too slow.

I don't think speed is so much an issue here, but scalability is. NIO
can handle multiple requests per thread, BIO cannot.

 
 
 Now, I'll try to run my tests using NIO, default VM configuration 
 and FINER logs.

Post the results when you get them. If the logs are relatively small,
just cut and paste into the mail message.

I suspect FINER is going to generate LOTS of logging and slow down
your application.

 
 Thanks a lot João

. . . . just my two cents
/mde/

 
 
 2014-07-03 14:07 GMT-03:00 Mark Eggers 
 its_toas...@yahoo.com.invalid:
 
 On 7/3/2014 9:12 AM, João Sávio wrote:
 cluster.log - http://pastebin.com/c98WhnmG
 
 
 2014-07-03 13:04 GMT-03:00 João Sávio joaosa...@gmail.com:
 
 Hello!
 
 Using NIO (with channelSendOptions=4, i.e.,
 synchronous), with lightly load, my tests pass 100%. But,
 on heavy load, not all sessions are replicated on time, and
 I have about 20% of errors. If I increase maxThreads to
 400, I have about 15% of errors.
 
 More information: * I am not performing parallel requests 
 with same session * my cluster has 4 nodes (all in one 
 machine - for test purpose only) * Java 7 64 bits, Tomcat 
 7.0.52, windows 7 64 bits * using default NIO 
 configuration, but with maxThreads=400 * VM options: 
 -Xms512M   - on real environment this value is 1024 
 -Xmx512M  - on real environment this value is 1024 
 -XX:NewSize=450M -XX:MaxNewSize=450M -XX:PermSize=128M 
 -XX:MaxPermSize=245M -XX:SurvivorRatio=8 
 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 
 -XX:+UseBiasedLocking -XX:CMSInitiatingOccupancyFraction=60
  -XX:+UseCMSInitiatingOccupancyOnly 
 -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC 
 -XX:+CMSIncrementalMode -XX:+UseParNewGC 
 -XX:+DisableExplicitGC -XX:+PrintGCDateStamps 
 -XX:+PrintGCDetails 
 -Xloggc:%CATALINA_BASE%/logs/tomcat-gc.log
 
 Moreover, I'm trying to attach the logs again.
 
 Thanks João
 
 João,
 
 I took a look at the log. This is the BIO attempt and you do run 
 out of threads. See the following:
 
 Jul 03, 2014 11:41:21 AM 
 org.apache.catalina.tribes.transport.bio.BioReceiver listen 
 WARNING: All BIO server replication threads are busy, unable to 
 handle more requests until a thread is freed up.
 
 What's the load like on the box when you're running the tests that 
 you get errors 

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
you mention NIO and say maxThreads, that sounds like the Connector
configuration, but the BIO receiver is on the cluster, and it a completely
different component that also has an applicable NIO configuration.

are you confusing the two?
I'm saying that you should use the NIO receiver on the cluster component,
and if you do, what kind of errors do you get?


On Thu, Jul 3, 2014 at 12:19 PM, Mark Eggers its_toas...@yahoo.com.invalid
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 João,

 This list has a convention of posting either inline or at the end of
 the message you're replying to.

 See here for mailing list notes:

 http://tomcat.apache.org/lists.html#tomcat-users

 On 7/3/2014 10:24 AM, João Sávio wrote:
  Hello
 
  Some points below:
 
  ** What is on time?* In my application, a group of users should
  always hit the same node after the first request. So, in first
  request each group of users will receive an specific cookie, and
  LB will perform the load balancing based on this cookie. In first
  request, a user can hit any node, but from the second, he or she
  should hit the same node.

 Hmm, so 'on time' really means that subsequent requests should hit the
 same server.

 If you're using sessions, Tomcat has an attribute on the Engine
 element called jvmRoute. So depending on your load balancer (and if
 you use AJP), you can use Tomcat and AJP to route traffic. In that
 case, there's no need to write a special cookie.

 At any rate, this doesn't sound like a clustering error per se.

 
  ** What are the errors? Test result errors?* For this test, I
  simplified the code of my application: - first request: store one
  object in session - second request: verify if the object is in
  session. If it's not - ERROR
 

 So looking at the information from 'on time', the scenario should be:

 1. first request, pick a random server and store a session object
 2. second request, pick the SAME server and ask for the session object

 Again, I'm not seeing where this is a clustering issue per se.

  ** How big are are the sessions that you're trying to replicate?*
  - I'm using Spring MVC, and I have 3 additional objects in
  session. They are not big (15 attributes each one)
 

 And all attributes are serializable? The objects are also marked as
 serializable?

  ** What's the load like on the box when you're running the tests
  that you get errors on?* - I've experiencing this issue on BIO
  even without load
 

 I may have not phrased my question carefully. What is the CPU and
 memory situation on your test box while running the 4 Tomcat servers?

 I know you've trimmed down your Xms and Xmx (presumably to fit in your
 test environment), but in combination with your other JVM parameters
 could this be causing some issues?

 I would follow Dan's recommendation of maybe just setting Xms, Xmx, GC
 logging to see what happens. Ah, I see you're going to do that below.

  ** It is preferred to use the non blocking receiver to be able to
  grow your cluster without running into thread starvation.* -
  That's why I've tried NIO first, but I'd like to see if BIO solve
  my issue and if using BIO my system doesn't get too slow.

 I don't think speed is so much an issue here, but scalability is. NIO
 can handle multiple requests per thread, BIO cannot.

 
 
  Now, I'll try to run my tests using NIO, default VM configuration
  and FINER logs.

 Post the results when you get them. If the logs are relatively small,
 just cut and paste into the mail message.

 I suspect FINER is going to generate LOTS of logging and slow down
 your application.

 
  Thanks a lot João

 . . . . just my two cents
 /mde/

 
 
  2014-07-03 14:07 GMT-03:00 Mark Eggers
  its_toas...@yahoo.com.invalid:
 
  On 7/3/2014 9:12 AM, João Sávio wrote:
  cluster.log - http://pastebin.com/c98WhnmG
 
 
  2014-07-03 13:04 GMT-03:00 João Sávio joaosa...@gmail.com:
 
  Hello!
 
  Using NIO (with channelSendOptions=4, i.e.,
  synchronous), with lightly load, my tests pass 100%. But,
  on heavy load, not all sessions are replicated on time, and
  I have about 20% of errors. If I increase maxThreads to
  400, I have about 15% of errors.
 
  More information: * I am not performing parallel requests
  with same session * my cluster has 4 nodes (all in one
  machine - for test purpose only) * Java 7 64 bits, Tomcat
  7.0.52, windows 7 64 bits * using default NIO
  configuration, but with maxThreads=400 * VM options:
  -Xms512M   - on real environment this value is 1024
  -Xmx512M  - on real environment this value is 1024
  -XX:NewSize=450M -XX:MaxNewSize=450M -XX:PermSize=128M
  -XX:MaxPermSize=245M -XX:SurvivorRatio=8
  -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15
  -XX:+UseBiasedLocking -XX:CMSInitiatingOccupancyFraction=60
   -XX:+UseCMSInitiatingOccupancyOnly
  -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC
  -XX:+CMSIncrementalMode -XX:+UseParNewGC
  -XX:+DisableExplicitGC -XX:+PrintGCDateStamps
  -XX:+PrintGCDetails
  

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hi everyone

I ran my test (total of 1k requests, total of 100 threads) against two
nodes with default VM settings. I've just set heap size. I had about 15% of
errors.

cluster.log - node1 - http://pastebin.com/cpX900Qw
cluster.log - node2 - http://pastebin.com/qCSzMaU6

Running for a long time (total of 500k requests, total of 100 threads) I
had about 11% of errors. In this case we can see the statistics:

Jul 03, 2014 5:53:28 PM
org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor report
INFO: ThroughputInterceptor Report[
Tx Msg:1 messages
Sent:12.36 MB (total)
 Sent:12.36 MB (application)
Time:7.82 seconds
Tx Speed:1.58 MB/sec (total)
 TxSpeed:1.58 MB/sec (application)
Error Msg:0
Rx Msg:10198 messages
 Rx Speed:0.08 MB/sec (since 1st msg)
Received:12.38 MB]


All session attributes are Serializable, and it's a session replication
issue because if I ran my test with just one node, I had 0% of errors.

Regarding on time, just a correction:

1. first request, pick a random server and store a session object
2. second request, pick *ANY* server (chose by LB based on the cookie - it
can be the same, but not necessarily) and ask for the session object.

To be more clean, I've been working with a conference system. Each
conference should occur in one node. So, the first request can hit any
server, and from the second request should hit the node where the
conference is.


Thanks a lot
João


2014-07-03 15:40 GMT-03:00 Filip Hanik fi...@hanik.com:

 you mention NIO and say maxThreads, that sounds like the Connector
 configuration, but the BIO receiver is on the cluster, and it a completely
 different component that also has an applicable NIO configuration.

 are you confusing the two?
 I'm saying that you should use the NIO receiver on the cluster component,
 and if you do, what kind of errors do you get?


 On Thu, Jul 3, 2014 at 12:19 PM, Mark Eggers its_toas...@yahoo.com.invalid
 
 wrote:

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  João,
 
  This list has a convention of posting either inline or at the end of
  the message you're replying to.
 
  See here for mailing list notes:
 
  http://tomcat.apache.org/lists.html#tomcat-users
 
  On 7/3/2014 10:24 AM, João Sávio wrote:
   Hello
  
   Some points below:
  
   ** What is on time?* In my application, a group of users should
   always hit the same node after the first request. So, in first
   request each group of users will receive an specific cookie, and
   LB will perform the load balancing based on this cookie. In first
   request, a user can hit any node, but from the second, he or she
   should hit the same node.
 
  Hmm, so 'on time' really means that subsequent requests should hit the
  same server.
 
  If you're using sessions, Tomcat has an attribute on the Engine
  element called jvmRoute. So depending on your load balancer (and if
  you use AJP), you can use Tomcat and AJP to route traffic. In that
  case, there's no need to write a special cookie.
 
  At any rate, this doesn't sound like a clustering error per se.
 
  
   ** What are the errors? Test result errors?* For this test, I
   simplified the code of my application: - first request: store one
   object in session - second request: verify if the object is in
   session. If it's not - ERROR
  
 
  So looking at the information from 'on time', the scenario should be:
 
  1. first request, pick a random server and store a session object
  2. second request, pick the SAME server and ask for the session object
 
  Again, I'm not seeing where this is a clustering issue per se.
 
   ** How big are are the sessions that you're trying to replicate?*
   - I'm using Spring MVC, and I have 3 additional objects in
   session. They are not big (15 attributes each one)
  
 
  And all attributes are serializable? The objects are also marked as
  serializable?
 
   ** What's the load like on the box when you're running the tests
   that you get errors on?* - I've experiencing this issue on BIO
   even without load
  
 
  I may have not phrased my question carefully. What is the CPU and
  memory situation on your test box while running the 4 Tomcat servers?
 
  I know you've trimmed down your Xms and Xmx (presumably to fit in your
  test environment), but in combination with your other JVM parameters
  could this be causing some issues?
 
  I would follow Dan's recommendation of maybe just setting Xms, Xmx, GC
  logging to see what happens. Ah, I see you're going to do that below.
 
   ** It is preferred to use the non blocking receiver to be able to
   grow your cluster without running into thread starvation.* -
   That's why I've tried NIO first, but I'd like to see if BIO solve
   my issue and if using BIO my system doesn't get too slow.
 
  I don't think speed is so much an issue here, but scalability is. NIO
  can handle multiple requests per thread, BIO cannot.
 
  
  
   Now, I'll try to run my tests using NIO, default VM configuration
   and FINER logs.
 
  Post the 

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
   1. are your machines in time sync? If they are not, a session can get
   timed out.
   2.
   3. SEVERE: Manager [localhost#/myApp]: Unable to receive message through
   TCP channel
   4. java.lang.IllegalStateException: setAttribute: Session [
   DEC3612CF763194E7953DB3FD2C433E0] has already been invalidated
   5. at org.apache.catalina.session.StandardSession.setAttribute(
   StandardSession.java:1437)
   6. at org.apache.catalina.ha.session.DeltaSession.setAttribute(
   DeltaSession.java:695)
   7. at org.apache.catalina.ha.session.DeltaRequest.execute(
   DeltaRequest.java:168)
   8. at
   org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(
   DeltaManager.java:1337)
   9. at org.apache.catalina.ha.session.DeltaManager.messageReceived
   (DeltaManager.java:1283)
   10. at
   org.apache.catalina.ha.session.DeltaManager.messageDataReceived(
   DeltaManager.java:1001)
   11. at
   org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(
   ClusterSessionListener.java:91)
   12. at
   org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(
   SimpleTcpCluster.java:943)
   13. at
   org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(
   SimpleTcpCluster.java:924)
   14. at
   org.apache.catalina.tribes.group.GroupChannel.messageReceived(
   GroupChannel.java:278)




On Thu, Jul 3, 2014 at 1:07 PM, João Sávio joaosa...@gmail.com wrote:

 Hi everyone

 I ran my test (total of 1k requests, total of 100 threads) against two
 nodes with default VM settings. I've just set heap size. I had about 15% of
 errors.

 cluster.log - node1 - http://pastebin.com/cpX900Qw
 cluster.log - node2 - http://pastebin.com/qCSzMaU6

 Running for a long time (total of 500k requests, total of 100 threads) I
 had about 11% of errors. In this case we can see the statistics:

 Jul 03, 2014 5:53:28 PM
 org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor report
 INFO: ThroughputInterceptor Report[
 Tx Msg:1 messages
 Sent:12.36 MB (total)
  Sent:12.36 MB (application)
 Time:7.82 seconds
 Tx Speed:1.58 MB/sec (total)
  TxSpeed:1.58 MB/sec (application)
 Error Msg:0
 Rx Msg:10198 messages
  Rx Speed:0.08 MB/sec (since 1st msg)
 Received:12.38 MB]


 All session attributes are Serializable, and it's a session replication
 issue because if I ran my test with just one node, I had 0% of errors.

 Regarding on time, just a correction:

 1. first request, pick a random server and store a session object
 2. second request, pick *ANY* server (chose by LB based on the cookie - it
 can be the same, but not necessarily) and ask for the session object.

 To be more clean, I've been working with a conference system. Each
 conference should occur in one node. So, the first request can hit any
 server, and from the second request should hit the node where the
 conference is.


 Thanks a lot
 João


 2014-07-03 15:40 GMT-03:00 Filip Hanik fi...@hanik.com:

  you mention NIO and say maxThreads, that sounds like the Connector
  configuration, but the BIO receiver is on the cluster, and it a
 completely
  different component that also has an applicable NIO configuration.
 
  are you confusing the two?
  I'm saying that you should use the NIO receiver on the cluster component,
  and if you do, what kind of errors do you get?
 
 
  On Thu, Jul 3, 2014 at 12:19 PM, Mark Eggers
 its_toas...@yahoo.com.invalid
  
  wrote:
 
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
  
   João,
  
   This list has a convention of posting either inline or at the end of
   the message you're replying to.
  
   See here for mailing list notes:
  
   http://tomcat.apache.org/lists.html#tomcat-users
  
   On 7/3/2014 10:24 AM, João Sávio wrote:
Hello
   
Some points below:
   
** What is on time?* In my application, a group of users should
always hit the same node after the first request. So, in first
request each group of users will receive an specific cookie, and
LB will perform the load balancing based on this cookie. In first
request, a user can hit any node, but from the second, he or she
should hit the same node.
  
   Hmm, so 'on time' really means that subsequent requests should hit the
   same server.
  
   If you're using sessions, Tomcat has an attribute on the Engine
   element called jvmRoute. So depending on your load balancer (and if
   you use AJP), you can use Tomcat and AJP to route traffic. In that
   case, there's no need to write a special cookie.
  
   At any rate, this doesn't sound like a clustering error per se.
  
   
** What are the errors? Test result errors?* For this test, I
simplified the code of my application: - first request: store one
object in session - second request: verify if the object is in
session. If it's not - ERROR
   
  
   So looking at the information from 'on time', the scenario should be:
  
   1. first request, pick a random server and 

Re: Where can I store data files in a tomcat war

2014-07-03 Thread Paul Taylor

On 03/07/2014 16:03, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 7/2/14, 4:28 PM, Paul Taylor wrote:

On 02/07/2014 16:34, Christopher Schultz wrote:

The solution is that the web application, packaged in a WAR
file, needs to unpack the Lucene indexes onto the disk when it
starts up. You can do this with a ServletContextListener.

So I do within init() method of my servlet, but EB doesnt wait for
the init() method to finish before declaring the application ready,
do you think it would wait for code using a ServletContextListener
or fail in the same way it does for init() ?

Which init() are you talking about?


GenericServlet.init(), is this method not designed for what I was doing


If EB marks the cluster node as
available before the webapp has completed deploying, that sounds like
a big problem. If you are using servlet.init() without any
load-on-startup for that servlet, then I would expect the bad behavior
you describe.
I dont understand what you are getting at here when you say 
'load-on-startup'

I think you'll have better luck with
ServletContextListener, because the servlet spec guarantees those to
be complete before the webapp can receive requests.
Okay, well the good news is that I now have it working with AWS 
ebextensions and it wasn't so difficult in the end.



You want to manage the streams yourself: hook a gzip reader up to a
tar reader and then read files from the tar reader:

GzipInputStream gzin = new GzipInputStream(tgzFile);
TarInputStream tin = new TarInputStream(gzin);

InputStream fin;

while(fin = tin.getNextFile())
copy(fin, new File(localFilename));

That's oversimplified, but essentially what you want to do. There is
no need to completely expand the gzip archive before reading files out
of it.

Ok, thanks good to know

thanks for your help

Paul

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



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hello Filip

The nodes are in the same machine!

Regards
João


Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Mark Eggers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Filip,

On 7/3/2014 12:11 PM, Filip Hanik wrote:
 1. are your machines in time sync? If they are not, a session can
 get timed out. 2. 3. SEVERE: Manager [localhost#/myApp]: Unable to
 receive message through TCP channel 4.
 java.lang.IllegalStateException: setAttribute: Session [ 
 DEC3612CF763194E7953DB3FD2C433E0] has already been invalidated 5.
 at org.apache.catalina.session.StandardSession.setAttribute( 
 StandardSession.java:1437) 6. at
 org.apache.catalina.ha.session.DeltaSession.setAttribute( 
 DeltaSession.java:695) 7. at
 org.apache.catalina.ha.session.DeltaRequest.execute( 
 DeltaRequest.java:168) 8. at 
 org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA( 
 DeltaManager.java:1337) 9. at
 org.apache.catalina.ha.session.DeltaManager.messageReceived 
 (DeltaManager.java:1283) 10. at 
 org.apache.catalina.ha.session.DeltaManager.messageDataReceived( 
 DeltaManager.java:1001) 11. at 
 org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(

 
ClusterSessionListener.java:91)
 12. at 
 org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived( 
 SimpleTcpCluster.java:943) 13. at 
 org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived( 
 SimpleTcpCluster.java:924) 14. at 
 org.apache.catalina.tribes.group.GroupChannel.messageReceived( 
 GroupChannel.java:278)
 
 

I think he's running the Tomcat cluster on the same physical machine
for testing.

So is the web application invalidating the session before the
attribute is replicated across the cluster?

/mde/

 
 
 On Thu, Jul 3, 2014 at 1:07 PM, João Sávio joaosa...@gmail.com
 wrote:
 
 Hi everyone
 
 I ran my test (total of 1k requests, total of 100 threads)
 against two nodes with default VM settings. I've just set heap
 size. I had about 15% of errors.
 
 cluster.log - node1 - http://pastebin.com/cpX900Qw cluster.log -
 node2 - http://pastebin.com/qCSzMaU6
 
 Running for a long time (total of 500k requests, total of 100
 threads) I had about 11% of errors. In this case we can see the
 statistics:
 
 Jul 03, 2014 5:53:28 PM 
 org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor
 report INFO: ThroughputInterceptor Report[ Tx Msg:1 messages 
 Sent:12.36 MB (total) Sent:12.36 MB (application) Time:7.82
 seconds Tx Speed:1.58 MB/sec (total) TxSpeed:1.58 MB/sec
 (application) Error Msg:0 Rx Msg:10198 messages Rx Speed:0.08
 MB/sec (since 1st msg) Received:12.38 MB]
 
 
 All session attributes are Serializable, and it's a session
 replication issue because if I ran my test with just one node, I
 had 0% of errors.
 
 Regarding on time, just a correction:
 
 1. first request, pick a random server and store a session
 object 2. second request, pick *ANY* server (chose by LB based on
 the cookie - it can be the same, but not necessarily) and ask for
 the session object.
 
 To be more clean, I've been working with a conference system.
 Each conference should occur in one node. So, the first request
 can hit any server, and from the second request should hit the
 node where the conference is.
 
 
 Thanks a lot João
 
 
 2014-07-03 15:40 GMT-03:00 Filip Hanik fi...@hanik.com:
 
 you mention NIO and say maxThreads, that sounds like the
 Connector configuration, but the BIO receiver is on the
 cluster, and it a
 completely
 different component that also has an applicable NIO
 configuration.
 
 are you confusing the two? I'm saying that you should use the
 NIO receiver on the cluster component, and if you do, what kind
 of errors do you get?
 
 
 On Thu, Jul 3, 2014 at 12:19 PM, Mark Eggers
 its_toas...@yahoo.com.invalid
 
 wrote:
 
 João,
 
 This list has a convention of posting either inline or at the end
 of the message you're replying to.
 
 See here for mailing list notes:
 
 http://tomcat.apache.org/lists.html#tomcat-users
 
 On 7/3/2014 10:24 AM, João Sávio wrote:
 Hello
 
 Some points below:
 
 ** What is on time?* In my application, a group of
 users should always hit the same node after the first
 request. So, in first request each group of users will
 receive an specific cookie, and LB will perform the load
 balancing based on this cookie. In first request, a user
 can hit any node, but from the second, he or she should
 hit the same node.
 
 Hmm, so 'on time' really means that subsequent requests should hit
 the same server.
 
 If you're using sessions, Tomcat has an attribute on the Engine 
 element called jvmRoute. So depending on your load balancer (and
 if you use AJP), you can use Tomcat and AJP to route traffic. In
 that case, there's no need to write a special cookie.
 
 At any rate, this doesn't sound like a clustering error per se.
 
 
 ** What are the errors? Test result errors?* For this
 test, I simplified the code of my application: - first
 request: store one object in session - second request:
 verify if the object is in session. If it's not - ERROR
 
 
 So looking at 

Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hello Mark

In fact, I'm not explicit invalidating session on this two requests.

Regards
João


[OT] Apache Tomcat7 service start randomly after the installation of McAfee antivirus

2014-07-03 Thread Leo Donahue
On Thu, Jul 3, 2014 at 4:22 AM, André Warnier a...@ice-sa.com wrote:

 Leo Donahue wrote:

 On Wed, Jul 2, 2014 at 2:33 AM, André Warnier a...@ice-sa.com wrote:

  Blachon, Philippe wrote:


 Why would one run a virus scanner permanently on a Tomcat server ?


 Does the OP work in the government?  My former employer had virus scanning
 software on every server.  You couldn't get a server image without it.

 The answer to that question is really based on policy, if he works in
 government.  Eventually, that server has the potential for getting a virus
 somehow from something or someone, and someone has to answer the question:
 why wasn't there virus scanning software on the server?


 Leo, I understand what you're saying above.
 But if one extrapolates that logic, then at some point the whole IT
 infrastructure and the whole Internet would grind to a halt, as only the
 POTUS would be allowed to upload anything onto a computer.


All sarcasm aside, I agree with you.  Some LAN administrators I've worked
with would applaud your statement though.

And I'll go one step further and add that not only in some local government
agencies you get virus scanners on servers, but you also get those system
scanners that monitor every single thing that happens on the server
(something related to the sun and wind)  It really bogs things down.

And it gets worse than that.  Sometimes you have eager admins who say:  I
see that this vm is only utilizing x % of the system resources, I'll either
degrade the existing resources provisioned on that server or maybe I'll
install something on it not related to the intent of that server.

All of that stuff makes troubleshooting problems so much harder.

At least his scheduled tasks are working.

leo


Re: Interface default methods

2014-07-03 Thread Leo Donahue
On Thu, Jul 3, 2014 at 1:05 AM, Mark Thomas ma...@apache.org wrote:

 On 3 July 2014 04:11:32 GMT+01:00, Leo Donahue donahu...@gmail.com
 wrote:
 I don't want to start a war, but just curious if the Tomcat developers
 see
 any use case for adding default methods to any of the Interfaces in the
 API?

 Which API?

 Mark


Well, for example, this Interface?
http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/Valve.java

I was just curious if the Tomcat developers have any intent on creating
default methods in Interfaces such as this one as opposed to using the
abstract class ValveBase.

Just wanted to know how people felt about Interface default methods in
general.

leo


Re: Interface default methods

2014-07-03 Thread Mark Thomas
On 03/07/2014 21:51, Leo Donahue wrote:
 On Thu, Jul 3, 2014 at 1:05 AM, Mark Thomas ma...@apache.org wrote:
 
 On 3 July 2014 04:11:32 GMT+01:00, Leo Donahue donahu...@gmail.com
 wrote:
 I don't want to start a war, but just curious if the Tomcat developers
 see
 any use case for adding default methods to any of the Interfaces in the
 API?

 Which API?

 Mark


 Well, for example, this Interface?
 http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/Valve.java
 
 I was just curious if the Tomcat developers have any intent on creating
 default methods in Interfaces such as this one as opposed to using the
 abstract class ValveBase.
 
 Just wanted to know how people felt about Interface default methods in
 general.

OK. We are talking about Tomcat's API that folks might use / Tomcat
internals.

Personally, I'm in favour of anything that enables us to write cleaner,
easier to maintain code. On that basis I guess I'd be happy to use them
where it made sense.

The obvious use case is when we add a new method to an interface. A
default method will enable to do this with a lower chance of causing
problems for folks using the interface.

In terms of using them instead of abstract classes, I think it depends.
There are times when having a final method in that base class is useful
- something I don't think you can do in an interface default method (I
could be wrong here).

When it comes to the existing code, I don't (currently) see a reason to
refactor the current abstract classes into interface default methods as
a standalone task. What I think is more likely is when a code section is
being refactored for some reason, interface default methods are another
tool that folks will consider when doing that refactoring.

All of this is, of course, dependent on the Servlet EG mandating a
minimum Java version that supports interface default methods for the
next spec release (which I think is pretty likely).

One thing to keep in mind: other committer opinions are available :)

Mark


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



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
Ok, at least the stack trace is clear. The session has been invalidated
somehow.
We would need to figure out when and how this happens, is it possible that
you are doing a clean shutdown of a tomcat instance and that instance
expires all the sessions? If that is the case, kill the tomcat with 'kill
-9' to simulate a failure. there is a flag called
'expireSessionsOnShutdown', do you have that set?





On Thu, Jul 3, 2014 at 2:05 PM, João Sávio joaosa...@gmail.com wrote:

 Hello Mark

 In fact, I'm not explicit invalidating session on this two requests.

 Regards
 João



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 7/3/14, 2:19 PM, Mark Eggers wrote:
 João,
 
 This list has a convention of posting either inline or at the end
 of the message you're replying to.
 
 See here for mailing list notes:
 
 http://tomcat.apache.org/lists.html#tomcat-users
 
 On 7/3/2014 10:24 AM, João Sávio wrote:
 Hello
 
 Some points below:
 
 ** What is on time?* In my application, a group of users should
  always hit the same node after the first request. So, in first 
 request each group of users will receive an specific cookie, and 
 LB will perform the load balancing based on this cookie. In first
  request, a user can hit any node, but from the second, he or she
  should hit the same node.
 
 Hmm, so 'on time' really means that subsequent requests should hit
 the same server.
 
 If you're using sessions, Tomcat has an attribute on the Engine 
 element called jvmRoute. So depending on your load balancer (and
 if you use AJP), you can use Tomcat and AJP to route traffic. In
 that case, there's no need to write a special cookie.
 
 At any rate, this doesn't sound like a clustering error per se.


I wonder if the real problem is a race condition: the cluster can't
replicate fast enough to stabilize before the second request comes in,
plus the lb configuration might not be correct.

João, can you confirm that request #1 and #2 are definitely hitting
the same Tomcat instance?

If you connect to TomcatA, set a session attribute, then reconnect to
TomcatA and get that session attribute, then it should be the same
unless something is awfully wrong. You don't even need to have
clustering enabled to test the above.

However if you hit TomcatA, set a session attribute, then connect to
TomcatB and try to get that session attribute, your request may have
arrived too early for the cluster to have pushed-out the session
attribute change.

So, if you can prove that both requests have gone to TomcatA and you
are getting errors, then there are several possibilities:

1. Tomcat has a huge bug and no web applications would work worldwide.
2. You are mishandling the setting of the session attribute
3. You are wrong about which server the client is hitting

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

iQIcBAEBCAAGBQJTtdBTAAoJEBzwKT+lPKRYtiwP/1dW2qplyepTgDTNixNw0viZ
29XFywsYAmDdMxzWcgkcl7Nrw3kVUcJVf+jLpxNCUxRJq7z4+zuyOLkImn2XW4a+
ygG1op69FSwsVEfQyHIH8OVjdYDUj6WPpP8bu2KbbkR0jtAiHO569+869WOvPyuA
z+oBhBhWB5w7e41qmQnLr6y3+hU19hGuayxkR61tqmZCPp6kpwRH2yN3IbhId2In
8DLoR5z6077jxPeXR6o3goB6Y9LbrPoYFUwdfQTpzrF8AvQ2wDl/CRuM2n9wB/ez
Oclnz0bw4JNegtarEJeiu4G1Qqf7WCqhVv4a8GfWYtr0ISk8GBBcCRjYZcoyU5IU
hSnNBGn586AhZ3BK5t1ySwrC6RiKH6MIR8fdBOSw1eZnTycPBSK6avZ4E8ahQDIp
uA93W+cME58gtmzdl2q7iLjRbwGdgebw++yfR4G42Tb4rUYsmOzsCPGx/nIqxB5E
FBea8xGwb802rFpYMxgMp8SzRy078RrDx2aptNfrb5oP9YeQ/pGrX9tVVtTlxNTk
8DKA8GHL4fiONAJB48iD2sTSv4jAhFInHnF4ykl0zjN7t3f0phMmSExeoH7HbFUI
G589M4KAs5X00xCSFt9gXdU+tpuFL+/x6kBAGrNmT5IySIvm+BfxTXjvg2daAjcC
+FAocYeosZumP5g2tICv
=1Si4
-END PGP SIGNATURE-

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



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
A race condition could happen if you set replication to happen async. But I
do have a memory of the configuration specifying synchronous replication,
which would guarantee that the replication changes have happened before the
request is complete.




On Thu, Jul 3, 2014 at 3:51 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Mark,

 On 7/3/14, 2:19 PM, Mark Eggers wrote:
  João,
 
  This list has a convention of posting either inline or at the end
  of the message you're replying to.
 
  See here for mailing list notes:
 
  http://tomcat.apache.org/lists.html#tomcat-users
 
  On 7/3/2014 10:24 AM, João Sávio wrote:
  Hello
 
  Some points below:
 
  ** What is on time?* In my application, a group of users should
   always hit the same node after the first request. So, in first
  request each group of users will receive an specific cookie, and
  LB will perform the load balancing based on this cookie. In first
   request, a user can hit any node, but from the second, he or she
   should hit the same node.
 
  Hmm, so 'on time' really means that subsequent requests should hit
  the same server.
 
  If you're using sessions, Tomcat has an attribute on the Engine
  element called jvmRoute. So depending on your load balancer (and
  if you use AJP), you can use Tomcat and AJP to route traffic. In
  that case, there's no need to write a special cookie.
 
  At any rate, this doesn't sound like a clustering error per se.


 I wonder if the real problem is a race condition: the cluster can't
 replicate fast enough to stabilize before the second request comes in,
 plus the lb configuration might not be correct.

 João, can you confirm that request #1 and #2 are definitely hitting
 the same Tomcat instance?

 If you connect to TomcatA, set a session attribute, then reconnect to
 TomcatA and get that session attribute, then it should be the same
 unless something is awfully wrong. You don't even need to have
 clustering enabled to test the above.

 However if you hit TomcatA, set a session attribute, then connect to
 TomcatB and try to get that session attribute, your request may have
 arrived too early for the cluster to have pushed-out the session
 attribute change.

 So, if you can prove that both requests have gone to TomcatA and you
 are getting errors, then there are several possibilities:

 1. Tomcat has a huge bug and no web applications would work worldwide.
 2. You are mishandling the setting of the session attribute
 3. You are wrong about which server the client is hitting

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

 iQIcBAEBCAAGBQJTtdBTAAoJEBzwKT+lPKRYtiwP/1dW2qplyepTgDTNixNw0viZ
 29XFywsYAmDdMxzWcgkcl7Nrw3kVUcJVf+jLpxNCUxRJq7z4+zuyOLkImn2XW4a+
 ygG1op69FSwsVEfQyHIH8OVjdYDUj6WPpP8bu2KbbkR0jtAiHO569+869WOvPyuA
 z+oBhBhWB5w7e41qmQnLr6y3+hU19hGuayxkR61tqmZCPp6kpwRH2yN3IbhId2In
 8DLoR5z6077jxPeXR6o3goB6Y9LbrPoYFUwdfQTpzrF8AvQ2wDl/CRuM2n9wB/ez
 Oclnz0bw4JNegtarEJeiu4G1Qqf7WCqhVv4a8GfWYtr0ISk8GBBcCRjYZcoyU5IU
 hSnNBGn586AhZ3BK5t1ySwrC6RiKH6MIR8fdBOSw1eZnTycPBSK6avZ4E8ahQDIp
 uA93W+cME58gtmzdl2q7iLjRbwGdgebw++yfR4G42Tb4rUYsmOzsCPGx/nIqxB5E
 FBea8xGwb802rFpYMxgMp8SzRy078RrDx2aptNfrb5oP9YeQ/pGrX9tVVtTlxNTk
 8DKA8GHL4fiONAJB48iD2sTSv4jAhFInHnF4ykl0zjN7t3f0phMmSExeoH7HbFUI
 G589M4KAs5X00xCSFt9gXdU+tpuFL+/x6kBAGrNmT5IySIvm+BfxTXjvg2daAjcC
 +FAocYeosZumP5g2tICv
 =1Si4
 -END PGP SIGNATURE-

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




Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
Hello Filip

I'm using channelSendOptions=4, which is supposed to be synchronous

Regards
João


Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
did you post your server.xml cause I can't find it?


On Thu, Jul 3, 2014 at 4:25 PM, João Sávio joaosa...@gmail.com wrote:

 Hello Filip

 I'm using channelSendOptions=4, which is supposed to be synchronous

 Regards
 João



Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
I don't think so.

Here it is: http://pastebin.com/qYCzmECb  (server.xml - node1)

Regards
João


Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread João Sávio
If I set channelSendOptions=8 (default value = asynchronous), the % of
errors increase (as expected)

Regards
João


2014-07-03 19:43 GMT-03:00 João Sávio joaosa...@gmail.com:

 I don't think so.

 Here it is: http://pastebin.com/qYCzmECb  (server.xml - node1)

 Regards
 João




-- 
http://joaosavio.wordpress.com


Re: Help with Tomcat 7 clustering using BIO receiver

2014-07-03 Thread Filip Hanik
Joao,
try channelSendOptions=6
this will mean that
1. You wish to use ACK's (option 2)
2. You wish the ACK to be synchronous

If you don't have the 0x0002 option enabled, it wont use ACKs at all.

Filip




On Thu, Jul 3, 2014 at 4:44 PM, João Sávio joaosa...@gmail.com wrote:

 If I set channelSendOptions=8 (default value = asynchronous), the % of
 errors increase (as expected)

 Regards
 João


 2014-07-03 19:43 GMT-03:00 João Sávio joaosa...@gmail.com:

  I don't think so.
 
  Here it is: http://pastebin.com/qYCzmECb  (server.xml - node1)
 
  Regards
  João
 



 --
 http://joaosavio.wordpress.com



can tomcat use aio instead of nio in linux?

2014-07-03 Thread Li Li
I have a background thread that is using hornetq client to receive jms
topic message from a remote hornetq broker. This thread is started as
ServletContextListener when tomcat starts.

But the tomcat throws strange Exception:

llegal access: this web application instance has been stopped already.
Could not load java.net.SocketTimeoutException.  The eventual
following stack trace is caused by an error thrown for debugging
purposes as well as to attempt to terminate the thread which caused
the illegal access, and has no functional impact.

java.lang.IllegalStateException

at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1588)

at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)

at 
org.jboss.netty.channel.socket.oio.AbstractOioWorker.run(AbstractOioWorker.java:75)

at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:51)

at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)

at 
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)

at 
org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:175)

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)

I suspect that hornetq use linux aio and cause jvm can't use nio which
is used by tomcat.
one solution may modify hornetq to use nio instead of aio. But I don't
know how to do it.
Another solution is letting tomcat using aio instead of nio. it it possilbe?

my os is ubuntu 12.04 with libaio installed. I can send and receive
topic messages in a standalone java application. My java version is :

java version 1.7.0_45

Java(TM) SE Runtime Environment (build 1.7.0_45-b18)

Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

tomcat version is 7.0.47

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