Re: Tomcat7 / Axis2

[Aurélien Terrestris]

Christopher,

"For dev/test, we sometimes have weeks with no activity, and I've never
seen any problems."

Let's suppose that during this no-activity period, you're restarting once
or twice the database. Or that a firewall silently dropped the connection.
Is the first request lost, Tomcat returning a 500 ?

"If you have to bounce Tomcat every day to keep your applications
running smoothly, it's the fault of your application, not of Tomcat."

Not only "my" applications, but many among the thousands that I had to deal
with in different large companies. Maybe there is a wrong understanding of
JDBC and how to use it, but if so many are failing to understand, this
means the poor documentation is somewhat responsible. Another point is that
developers like to copy/paste their old code which they believe is
fail-safe, bringing the same bugs again and again.

best regards





2016-08-23 22:33 GMT+02:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Aurélien,
>
> On 8/22/16 3:36 PM, Aurélien Terrestris wrote:
> > "We have a Tomcat 7 and Axis 2 for our Java SOAP web service over
> > https on our Ubuntu server. We also use C3PO connection pooling
> > (also in other web services which is working fine). However, I´m
> > not sure if this is related to the topic."
> >
> > I believe it is. Is the faulty web service getting requests all the
> > time, or there are some long time without requests ? I can't speak
> > for all the mailing list, but myself I do a daily restart of my
> > Tomcats to prevent such problem.
>
> I only restart my Tomcats for application upgrades. We use Tomcat's
> DBCP2-based connection pool. We don't have very many periods of
> inactivity in production.
>
> For dev/test, we sometimes have weeks with no activity, and I've never
> seen any problems.
>
> If you have to bounce Tomcat every day to keep your applications
> running smoothly, it's the fault of your application, not of Tomcat.
>
> - -chris
>
> > 2016-08-22 17:32 GMT+02:00 Matthias Schmitt
> > :
> >
> >> Hello everybody,
> >>
> >> We have a Tomcat 7 and Axis 2 for our Java SOAP web service over
> >> https on our Ubuntu server. We also use C3PO connection pooling
> >> (also in other web services which is working fine). However, I´m
> >> not sure if this is related to the topic.
> >>
> >> The web service is working for about two/three days and after
> >> that time period it´s not working anymore. Then our consuming
> >> customer receives a Read Timeout Exception. After restarting the
> >> Tomcat servlet everything is working fine again. Processing the
> >> request has a duration of about 3 seconds. The Axis 2 has a
> >> default socket timeout of 30 seconds. Our customer has a wait
> >> timeout of 60 seconds. The strange thing about the problem is
> >> that it´s working for amount of time and then the problem occurs.
> >> Even if we increase the client timeout it seems like the request
> >> will be not processed. Also increasing the socket timeout value
> >> in axis configuration does not take effect. There is no exception
> >> message in the log that could help us to reproduce the problem.
> >>
> >> Thanks for your help,
> >>
> >> Mit besten Grüßen/with best regards
> >>
> >> Matthias Schmitt
> >>
> >>
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXvLMWAAoJEBzwKT+lPKRYwsgQAJKGwx+rRl8L/PM/rQKX/3Mz
> ml0aYb+9rHeALymvzqy7Q+AcrYZOUqxCnyl9JtYbjIw12QHqUa5KKt2aAS2Uha8B
> H3yOs7cVCW/ZIdYEtyFwDGKvbexM5nXEeE8ZeNn184Qdb+r9bSAZs3mrM3QWxfG3
> aw51J2h0dCEG2sHE7P/N4U/IvbthoI5OSVWsSEB7AJs8GOrHhX9ZJ/KRiY/i5bna
> 5I9BlzOHgCUBDUaD7p2BTBiMSAolB0SA5wT9sm5ITJRUvvBCs/kg1kA6EMJBTX1A
> RNBGlPJus91DthG/a39dcb/PbrXwGpTc4E1g4QtdpVAQEKrmZK7hOrhD9EeYiSOr
> ADyPM7WRNdemdmrJhMmS9gbGfbCSFhFnxKHxeRUBC/lSPCsVFX89CDfCRoqpya6L
> 1scIt0eOC68I40Z6ME/0vVSevtcjvESXBRhPquIKviHYKlEeLpqZ+/0V8wC3sCmG
> 9E3OAPmY5C5EuMtV5XMTT4iojojR0dt73/CZFvvhrc1e2GY0bdgFaXf5/+nGDUcr
> TYuGzPwyQTnJRnBOXfF8i6KiG77OnQ8vE8TtS6CEcVXNusSK2mjf8zxvGcs9Ietw
> 8eqLPPLyWYrnqyXUMBZXa/XJeH8qHZYmBpv4O6xgeYRTcnERC1EJof5KzsXtjDJT
> mueggk9xS2aBwMGgk04M
> =II6y
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 7 context.xml update questions

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 8/22/16 1:08 PM, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK
INFORMATION INC at Cisco) wrote:
> I have two questions regarding an update to the context.xml file. 
> First I understood that any changes made to the context.xml file 
> would not be read until the Tomcat instance was restarted.

That depends upon your configuration. Tomcat's default configuration
will reload your application if anything about your app's
META-INF/context.xml changes.

> I updated the removeAbandonedTimeout attribute from 90 to 300 
> seconds planning on restarting the Tomcat instance later today,
> but Tomcat restarted automatically after I saved the update. I did
> not know Tomcat was monitoring for changes in the context file, and
> then would restart if any changes were detected. Is that standard 
> behavior?

Yes. Have a look at
https://tomcat.apache.org/tomcat-8.0-doc/config/host.html#Automatic_Appl
ication_Deployment

> Second now that the new attribute entry was supposedly picked up,
> how do I confirm it is now 300 seconds? I don't see that attribute
> in the default server status page.

What default server status page?

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

iQIcBAEBCAAGBQJXvLVLAAoJEBzwKT+lPKRYSt8QAMDa+tlCGEDEEkg/TzG5oXQV
nHMdPdCVba/Hh6BxiD5Z4zvF7YFh/liKXlrUAK8HSALK+sc5M7YKBGDMy+fAPNLF
e3kEPXMeo4MNZWr4j9DKc6j3ix1vcou4sbb0ViyzHcS6yNtekbw0iZ9Q8zjq9TwO
6AasfQZI07JGExP0wvml6dwtv5L7tggbGLhCtc45sRVKry1Ia/GCTdGqkLWpYMU1
+hFxvK3llyjVmn0kEeIizHX/NyQRhi34puvuuE/rF1k7L1w+pmf3VzvDtrEbgkuf
MXtughUVwyg50LtwnGRCq7r4ISWDigray/2vrGkAFyb4UDxHnBoAIZ7dxIIfZt8H
hquLkKj4WA+pYnbx3xs5tyRgBZFP1vkTIZZxWcc7YpHJJmrBfOV14kOR9Q32YnLK
yzfgqIohCc2V+GaeVSvtJkVm9txoYbCcAkdZHij6ewUc6CwyNPRvXitFpAzM/Av3
MPHnGrE7E5UqlmyqRPiTtHDHW2/AtLO5V9K9Sg3VkDi1nWMKHDKfsrw5t+fJ0pbK
82H7KnMU4otu/hd+MZ5HbX7c9MLvxSuljar/gwtSGLn7/dPSEh+jZ/Pv8e7QVO4U
D+P71NED2gJ+qfS/15B9gH9VeqoCeRyYuc5e4lfy2n2B6mis8eOCU59TqjYVm6nG
f6QzRX627onrutcWHQub
=umLb
-END PGP SIGNATURE-

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

Re: Tomcat7 / Axis2

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Aurélien,

On 8/22/16 3:36 PM, Aurélien Terrestris wrote:
> "We have a Tomcat 7 and Axis 2 for our Java SOAP web service over
> https on our Ubuntu server. We also use C3PO connection pooling
> (also in other web services which is working fine). However, I´m
> not sure if this is related to the topic."
> 
> I believe it is. Is the faulty web service getting requests all the
> time, or there are some long time without requests ? I can't speak
> for all the mailing list, but myself I do a daily restart of my
> Tomcats to prevent such problem.

I only restart my Tomcats for application upgrades. We use Tomcat's
DBCP2-based connection pool. We don't have very many periods of
inactivity in production.

For dev/test, we sometimes have weeks with no activity, and I've never
seen any problems.

If you have to bounce Tomcat every day to keep your applications
running smoothly, it's the fault of your application, not of Tomcat.

- -chris

> 2016-08-22 17:32 GMT+02:00 Matthias Schmitt
> :
> 
>> Hello everybody,
>> 
>> We have a Tomcat 7 and Axis 2 for our Java SOAP web service over
>> https on our Ubuntu server. We also use C3PO connection pooling
>> (also in other web services which is working fine). However, I´m
>> not sure if this is related to the topic.
>> 
>> The web service is working for about two/three days and after
>> that time period it´s not working anymore. Then our consuming
>> customer receives a Read Timeout Exception. After restarting the
>> Tomcat servlet everything is working fine again. Processing the
>> request has a duration of about 3 seconds. The Axis 2 has a
>> default socket timeout of 30 seconds. Our customer has a wait
>> timeout of 60 seconds. The strange thing about the problem is
>> that it´s working for amount of time and then the problem occurs.
>> Even if we increase the client timeout it seems like the request 
>> will be not processed. Also increasing the socket timeout value
>> in axis configuration does not take effect. There is no exception
>> message in the log that could help us to reproduce the problem.
>> 
>> Thanks for your help,
>> 
>> Mit besten Grüßen/with best regards
>> 
>> Matthias Schmitt
>> 
>> 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXvLMWAAoJEBzwKT+lPKRYwsgQAJKGwx+rRl8L/PM/rQKX/3Mz
ml0aYb+9rHeALymvzqy7Q+AcrYZOUqxCnyl9JtYbjIw12QHqUa5KKt2aAS2Uha8B
H3yOs7cVCW/ZIdYEtyFwDGKvbexM5nXEeE8ZeNn184Qdb+r9bSAZs3mrM3QWxfG3
aw51J2h0dCEG2sHE7P/N4U/IvbthoI5OSVWsSEB7AJs8GOrHhX9ZJ/KRiY/i5bna
5I9BlzOHgCUBDUaD7p2BTBiMSAolB0SA5wT9sm5ITJRUvvBCs/kg1kA6EMJBTX1A
RNBGlPJus91DthG/a39dcb/PbrXwGpTc4E1g4QtdpVAQEKrmZK7hOrhD9EeYiSOr
ADyPM7WRNdemdmrJhMmS9gbGfbCSFhFnxKHxeRUBC/lSPCsVFX89CDfCRoqpya6L
1scIt0eOC68I40Z6ME/0vVSevtcjvESXBRhPquIKviHYKlEeLpqZ+/0V8wC3sCmG
9E3OAPmY5C5EuMtV5XMTT4iojojR0dt73/CZFvvhrc1e2GY0bdgFaXf5/+nGDUcr
TYuGzPwyQTnJRnBOXfF8i6KiG77OnQ8vE8TtS6CEcVXNusSK2mjf8zxvGcs9Ietw
8eqLPPLyWYrnqyXUMBZXa/XJeH8qHZYmBpv4O6xgeYRTcnERC1EJof5KzsXtjDJT
mueggk9xS2aBwMGgk04M
=II6y
-END PGP SIGNATURE-

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

Re: Sporadic High CPU consumption on 8.5.x

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

On 8/22/16 11:27 AM, Chuck Syperski wrote:
> I think I found a larger part of the puzzle with the OpenSSL
> support for tomcat, it looks like when using the ssl config
> provided below (directly from Let's encrypt in this case) in your
> server.xml you can consume a large amount of a server's CPU.
> 
>  certificateFile="conf/localhost-rsa-cert.pem" 
> certificateChainFile="conf/localhost-rsa-chain.pem" type="RSA" />
> 
> If you use this config and you attempt to connect using IE8, it
> will fail to load the page on the client and kill one core of your
> box until you restart.
> 
> Can someone attempt to reproduce this?  It works against the manage
> app (https://.../manager/html)
> 
> I was able to replicate using this site if you don't have an XP box
> laying around.
> 
> http://netrenderer.com/index.php
> 
> My setup is Ubuntu 16.04, tomcat 8.5.3 and Oracle Java
> 1.8.0_101-b13

This is using the NIO or NIO2 connector, right?

I haven't yet tried to reproduce this, but I did take a casual look at
the thread dump. The only candidates I see for killing the CPU are the
accept() and epoll() calls. accept() should be basically a "free" call
that blocks 100% and does nothing unless there are incoming connections.

The select() call for NIO can be either cheap or expensive depending
upon what's going on in the fd list and the timeout used for checking.
I suspect a busy-wait with the select/epoll call(s). The only way to
prove that would be to use strace or equivalent, and on a JVM that is
going to be a huge mess of calls. You might be able to filter it with
grep to see how often the underlying kernel calls are being made -- it
they are being made e.g. thousands of times per second then there's
the problem.

Have you tried any of the other versions in the 8.5.x line? I don't
see anything in the 8.5.4 changelog that would seem to affect this,
but it's worth trying.

Also please try 8.5.0 and, if possible, 9.0. 9.0.x and 8.5.x are very
closely related when it comes to the changes that have been made to
the various connectors. If there are some versions that don't fail,
then it can help determine what change(s) may have broken something.

There have recently been a few changes to the way NIO/NIO2 manage
connections, fds, etc. and those changes may have caused/fixed this issu
e.

If you are using NIO, can you try NIO2 and if NIO2 try NIO instead?
That could help narrow things down as well.

Thanks,
- -chris

> On Mon, Aug 22, 2016 at 9:40 AM, Chuck Syperski
>  wrote:
> 
>> Hello,
>> 
>> I am having an issue with a product box running tomcat 8.5.3
>> consuming a high percent of CPU cycles on a single core at what
>> seems like random intervals (typically days apart), trigger by
>> nothing other than a simple http get request. This didn’t happen
>> when I was using the 8.0.x branch with SSL using a  JKS.  I have
>> switched to using the OpenSSL method in 8.5.3 as well (see
>> configuration below), so I don’t know if that could contribute
>> to the issues I am having
>> 
>> > certificateFile="conf/localhost-rsa-cert.pem" 
>> certificateChainFile="conf/ localhost-rsa-chain.pem" type="RSA"
>> />
>> 
>> I’ve gone years without any issue until recently (with the
>> general changes outlined above).  When the issue is occuring  I
>> noticed when looking at “top”  the “system” cpu percent is higher
>> then the user space percent (ie: 30% us, 50% sys), and it stays
>> pretty stable at the split.  This will continue until I restart
>> tomcat, and I found that undeploying my webapp didn’t stop the
>> run away cpu, only restarting tomcat would stop the process.
>> 
>> I’m running ubuntu 16.04, with java version "1.8.0_101"
>> 
>> I understand there isn’t a lot of details to go on here, I’ve
>> included my thread dump and jstack below:
>> 
>> jstack - http://pastebin.com/5Y2C5hzu
>> 
>> threaddump - http://pastebin.com/n9Rkybwv
>> 
>> Any pointers as to where to look next would be appreciated, as
>> I’m a bit stuck as to what I should look at next.
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXvHd6AAoJEBzwKT+lPKRYSO0P/1BY62BwyH6rLlfiWBaW3tbk
mWBhI6+BeZB0uzhHrJN37GsElAjbDi+Vs3riOibR/mzKbVWYbCs0EMAG7ltB2QlE
vJnjjGT0z9QNIgrHdyvcV+JrXxF5Vf+4CnK9um/ZlHFKZGpkAabYJauQB3EvK+7w
M0RxjrX4yM8Ta6QF1HSlB3MFtMtXDcS/ZtjzSvDUw6nLQ0zWExtuXuWBRvkQmDkL
7mrbVo2bSmzyJyLJuDWM2NXo/M/jI6u5zNsGR+kXSEVbYXkIOW3otg/IImx9xzta
RBxWgoc59YF6Jp62SHLBtGebrwV9vqzFRLkVoSdxF8aAikftuYkiS78QBlhv2D8u
ooIVhcXBSwC2lzJSne/N+UIzmDS/kr8CmOThxfH8JHU7TGSa8fsespxxQ8JUqtb+
YeaZPymVuapx2V2TKd83Qwjfb5onnbWoMNGGETvD0tPN8qWg0rk7gLsbNoHZHu5U
fyRgtbmM86sCfYi7P1tPeANPLJpqYxWb2HXwdmXTBlAEySesfEkxp3q4bbB9rAFv
KTSGYEU3TDSnM9ZXrWzhR53PYIkMeesd6xu/NoHdedCp57e96tB9SEbhTl2dBRZl
UxZFSuyIrqJaclM7MDZtlLyi6a1dC2N0YO574RsrDNp/We7IhqIUWtQ8vynpFUlQ
pVWjSSebsl012Ej7h8+g
=ryhm
-END PGP SIGNATURE-

Re: Question about suspectTimeout property of pool configuration - possible Bug - does only work with removeAbandoned = true which seems odd

[Keiichi Fujino]

2016-08-19 0:52 GMT+09:00 Torsten Krah :

> Hi,
>
> looking at the doc:
>
> https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
>
> there is:
>
> suspectTimeout
>
> (int) Timeout value in seconds. Default value is 0.
> Similar to to the removeAbandonedTimeout value but instead of treating
> the connection as abandoned, and potentially closing the connection,
> this simply logs the warning if logAbandoned is set to true. If this
> value is equal or less than 0, no suspect checking will be performed.
> Suspect checking only takes place if the timeout value is larger than 0
> and the connection was not abandoned or if abandon check is disabled. If
> a connection is suspect a WARN message gets logged and a JMX
> notification gets sent once.
>
> To me this sounds like i should get a warning if i configure the pool
> like this:
>
>  logAbandoned="true"
>  suspectTimeout="120"
>
> after 2 minutes.
> I don't want to remove the connections, i just want to get them logged.
>
> However i don't see such messages - looking at the code it seems that
> suspect() from the connection is called from the pool in:
>
> pool.checkAbandoned();
>
> but this is only called from the PoolCleaner in its run method when the
> check:
>
> if (pool.getPoolProperties().isRemoveAbandoned())
> pool.checkAbandoned();
>
> is true.
> But i don't want to get them removed - i just want them logged like
> suspect is promising - at least it sounds to me like that.
>
> Any thoughts about that? Shouldn't it read like:
>
> if (pool.getPoolProperties().isRemoveAbandoned() ||
> pool.getPoolProperties().getSuspectTimeout() > 0)
> pool.checkAbandoned();
>
> JavaDoc of setSuspectTimeout:
>
> /**
>  * Similar to {@link #setRemoveAbandonedTimeout(int)} but instead of
> treating the connection
>  * as abandoned, and potentially closing the connection, this simply
> logs the warning if
>  * {@link #isLogAbandoned()} returns true. If this value is equal or
> less than 0, no suspect
>  * checking will be performed. Suspect checking only takes place if
> the timeout value is larger than 0 and
>  * the connection was not abandoned or if abandon check is disabled.
> If a connection is suspect a WARN message gets
>  * logged and a JMX notification gets sent once.
>  * @param seconds - the amount of time in seconds that has to pass
> before a connection is marked suspect.
>  */
> public void setSuspectTimeout(int seconds);
>
>
> does also imply this behaviour i would expect.
> It seems you need to remove them (even with a large timeout set to get
> suspect working) - javadoc reads i can have suspect without remove.
> If this should be the case checkAbandoned() needs some work so that
> shouldAbandon() does check the property - removeAbandoned - to make sure
> it should really remove it, not just got to suspect in the else case -
> or just have to methods ... don't mind which solution, something like
> this ;).
>
> Should i open some ticket about that possible Bug or is it working as
> intended?
>
>
Hello Torsten

I'm not sure whether this is a bug.
However, I prefer the suspectTimeout does not depend on the removeAbandoned.
The suspectTimeout should work without abandoned connection.

Please open the bugzilla.




> kind regards
>
> Torsten
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
> Keiichi.Fujino
> 

Re: Tomcat7 / Axis2

[Matthias Schmitt]

Hello,

Thanks for your help.

The article with the C3PO helper threads is very interesting.

Mit besten Grüßen/with best regards
 
Matthias Schmitt





Am 22.08.16, 21:48 schrieb "Mark Eggers" :

>Matthias,
>
>On 8/22/2016 8:32 AM, Matthias Schmitt wrote:
>> Hello everybody,
>> 
>> We have a Tomcat 7 and Axis 2 for our Java SOAP web service over
>> https on our Ubuntu server. We also use C3PO connection pooling (also
>> in other web services which is working fine). However, I´m not sure
>> if this is related to the topic.
>> 
>> The web service is working for about two/three days and after that
>> time period it´s not working anymore. Then our consuming customer
>> receives a Read Timeout Exception. After restarting the Tomcat
>> servlet everything is working fine again. Processing the request has
>> a duration of about 3 seconds. The Axis 2 has a default socket
>> timeout of 30 seconds. Our customer has a wait timeout of 60 seconds.
>> The strange thing about the problem is that it´s working for amount
>> of time and then the problem occurs. Even if we increase the client
>> timeout it seems like the request will be not processed. Also
>> increasing the socket timeout value in axis configuration does not
>> take effect. There is no exception message in the log that could help
>> us to reproduce the problem.
>> 
>> Thanks for your help,
>> 
>> Mit besten Grüßen/with best regards
>> 
>> Matthias Schmitt
>
>A thread dump when things are stuck would probably tell you a bit.
>
>That being said, I did a quick search on connection pooling
>implementations for Java, and found an interesting article:
>
>http://www.trustiv.co.uk/2014/06/battle-connection-pools
>
>It seems (at least in 2014) that if there are too few cp30 helper
>threads, you might end up with the behavior that you're seeing.
>
>It's just a thought. I have no experience with cp30 in this scenario.
>
>. . . just my two cents.
>/mde/
>


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

Re: Tomcat7 / Axis2

[Matthias Schmitt]

Hello,

Thanks for your help.

Yes, the faulty web service is standing still for some time (sometimes 2 days).
Then a request is coming in and it´s not working then. A daily restart could be
an option. However, the Tomcat contains multiple endpoints which are working 
fine.

Mit besten Grüßen/with best regards
 
Matthias Schmitt






Am 22.08.16, 21:36 schrieb "Aurélien Terrestris" :

>"We have a Tomcat 7 and Axis 2 for our Java SOAP web service over https on
>our Ubuntu server. We also use C3PO connection pooling (also in other web
>services which is working fine). However, I´m not sure if this is related
>to the topic."
>
>I believe it is. Is the faulty web service getting requests all the time,
>or there are some long time without requests ?
>I can't speak for all the mailing list, but myself I do a daily restart of
>my Tomcats to prevent such problem.
>
>
>2016-08-22 17:32 GMT+02:00 Matthias Schmitt :
>
>> Hello everybody,
>>
>> We have a Tomcat 7 and Axis 2 for our Java SOAP web service over https on
>> our Ubuntu server. We also use C3PO connection pooling (also in other web
>> services which is working fine). However, I´m not sure if this is related
>> to the topic.
>>
>> The web service is working for about two/three days and after that time
>> period it´s not working anymore. Then our consuming customer receives a
>> Read Timeout Exception. After restarting the Tomcat servlet everything is
>> working fine again. Processing the request has a duration of about 3
>> seconds. The Axis 2 has a default socket timeout of 30 seconds. Our
>> customer has a wait timeout of 60 seconds. The strange thing about the
>> problem is that it´s working for amount of time and then the problem
>> occurs. Even if we increase the client timeout it seems like the request
>> will be not processed. Also increasing the socket timeout value in axis
>> configuration does not take effect. There is no exception message in the
>> log that could help us to reproduce the problem.
>>
>> Thanks for your help,
>>
>> Mit besten Grüßen/with best regards
>>
>> Matthias Schmitt
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>


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