Re: Tomcat 7.0.54

[Konstantin Kolinko]

пт, 24 февр. 2023 г. в 00:42, :
>
> Hi all
>
>
>
> Can you tell me if there is a difference between Tomcat 7.0.54 with Oracle
> JRE 1.8.0_221 and OpenJDK 1.8.0_342 from a functional perspective? Can it
> be, that certain DB transactions are handled different between these two
> java versions? Yes, I know, Tomcat 7.0.54 is . old, legacy, vulnerable - but
> still, if someone knows, I would appreciate the reply.

1. Regarding differences between Java 1.8.0_221 and 1.8.0_342, you can
read release notes provided by Oracle.

In general, usually there are the following changes
- updates to the time zone database
- security updates, such as disabling weak ciphers

Though I think that OpenJDK may use the time zone database provided by
the operating system.

2. If your Tomcats run on different systems, or under different user accounts,
I would pay attention to timezone and locale settings for those.

In my country I sometimes see documents (such as receipts) generated
by misconfigured systems, using a different decimal separator
character in numbers (point vs comma), different format for dates, or
having daylight time changes when there should have been none.

Best regards,
Konstantin Kolinko

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

Re: Tomcat 7.0.54

[Mark Thomas]

On 23/02/2023 21:41, a.grub...@bluewin.ch wrote:

Hi all

Can you tell me if there is a difference between Tomcat 7.0.54 with Oracle
JRE 1.8.0_221 and OpenJDK 1.8.0_342 from a functional perspective?


Tomcat should behave exactly the same way with either of those JVMs. 
However, the Tomcat project can't guarantee that. Further, given that 
Tomcat 7.0.x reached end of life almost 2 years ago, if you do find a 
difference in behaviour, you are unlikely to get a Tomcat committer 
interested in investigating and fixing the issue unless it also occurs 
on a currently supported Tomcat version. And even if you manage that, 
you are almost certainly not going to get a fix for Tomcat 7.0.x.



Can it
be, that certain DB transactions are handled different between these two
java versions?


Again, they should be but the Tomcat project can't guarantee that.

Mark



Yes, I know, Tomcat 7.0.54 is . old, legacy, vulnerable - but
still, if someone knows, I would appreciate the reply.

  


Thanks for your feedback.

Alexander




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

Tomcat 7.0.54

[a.grubner]

Hi all

 

Can you tell me if there is a difference between Tomcat 7.0.54 with Oracle
JRE 1.8.0_221 and OpenJDK 1.8.0_342 from a functional perspective? Can it
be, that certain DB transactions are handled different between these two
java versions? Yes, I know, Tomcat 7.0.54 is . old, legacy, vulnerable - but
still, if someone knows, I would appreciate the reply.

 

Thanks for your feedback.

Alexander

RE: Application hanging on Tomcat 7.0.54

[Louis Zipes]

Ok, thanks as always for the advice!  We think we figured out the user error(s) 
that caused the issue but I'm now more comfortable with pulling the Thread 
Dumps/VisualVM quicker so we can at least get those before we have to restart 
the application.

Thanks, Louis





> timeout set to 60.  Should I be looking to turn on some tracing on the
> driver?
60 what?

60 was the Pool Timeout

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, September 28, 2018 6:43 PM
To: users@tomcat.apache.org
Subject: Re: Application hanging on Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/27/18 09:19, Louis Zipes wrote:
> Even though these hangs are critical to find, any plugin or
> additional code that I wish to put on our PRD server have to go
> through our SOX process so it can be cumbersome.  Are any of the
> monitoring techniques that you mention 'out of the box' with
> Tomcat 7.0.54 or JDK 1.7.  I can certainly open the JCONSOLE in the
> java bin folder  but I don't have those nice Spring Boot Add-ons
> documented in say
> https://stackoverflow.com/questions/36587023/how-to-debug-log-tomcat-j
dbc-connection-pools-connections

You
>
>
don't need Spring Boot or anything like that. jconsole (or, better
yet VisualVM) can certainly observe your connection pool status as well
as runtime thread state, etc.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurl0ACgkQHPApP6U8
pFjcdBAAqDBUm3gIasaDXdo0b0ZSyL56ADyTNa4c3hDdXLy4KJQjhYEltm23JktE
VCdTDdZj7T/dYAqyJvNXugak4f4SkBS5BhGyHBK+mfLmT8H3rqNNi+lUHHLlPHJn
O03YZfNz/HtYpajSgReaFm8SQQ/9RYhtlyVA0ZH+6UH1RVsGAxnqNAaUReCMyR1r
sN4lhwzft/xQCJ+riQ+rtrgeCpQJaZts88Bph8PFQ9CMKu1tWDU4RvgqyxMJ3uzm
Ciq4wQ5zU8ke5nDuiLryfli7ODj07pDgt0HJTfVggbeNi8psNps2We+s0sjLFwbs
ldw27q00H7vJsgyds0FDtbqoGQ1C8WkmfO/L6G47VxO55Jps8O4nbaaweRNtDWJO
N/RuBU2UvvzVgKuKtzBNXnKF7mIEssSLnb0OyY7ANuQBwhy/FmcHWey79VLYvsKt
ZD9DzCKE0ekJLg1Pfc2bMQsiDI/O9lFB/6JeknLs7fde1b9j3+8DeL/kUDHEt4go
lG2rs44/2GqTfNdhBEU8ERIaxretstK/ms3/zLoeVYO7VQypHeeagDHH7TOfztbR
hlYX5egZRCs0VT61gp4A2BONhbSWcldFbrUa8zRXnYLPe0WZMUEcmDsVt7YXv85x
2UJtZL6jFawEr91L8bjB9bKPBQFdilJFok1o/iib1ltXhXsTItE=
=IVM1
-END PGP SIGNATURE-

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

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

Re: Application hanging on Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/27/18 09:19, Louis Zipes wrote:
> Even though these hangs are critical to find, any plugin or 
> additional code that I wish to put on our PRD server have to go 
> through our SOX process so it can be cumbersome.  Are any of the 
> monitoring techniques that you mention 'out of the box' with
> Tomcat 7.0.54 or JDK 1.7.  I can certainly open the JCONSOLE in the
> java bin folder  but I don't have those nice Spring Boot Add-ons
> documented in say 
> https://stackoverflow.com/questions/36587023/how-to-debug-log-tomcat-j
dbc-connection-pools-connections

You
>
> 
don't need Spring Boot or anything like that. jconsole (or, better
yet VisualVM) can certainly observe your connection pool status as well
as runtime thread state, etc.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurl0ACgkQHPApP6U8
pFjcdBAAqDBUm3gIasaDXdo0b0ZSyL56ADyTNa4c3hDdXLy4KJQjhYEltm23JktE
VCdTDdZj7T/dYAqyJvNXugak4f4SkBS5BhGyHBK+mfLmT8H3rqNNi+lUHHLlPHJn
O03YZfNz/HtYpajSgReaFm8SQQ/9RYhtlyVA0ZH+6UH1RVsGAxnqNAaUReCMyR1r
sN4lhwzft/xQCJ+riQ+rtrgeCpQJaZts88Bph8PFQ9CMKu1tWDU4RvgqyxMJ3uzm
Ciq4wQ5zU8ke5nDuiLryfli7ODj07pDgt0HJTfVggbeNi8psNps2We+s0sjLFwbs
ldw27q00H7vJsgyds0FDtbqoGQ1C8WkmfO/L6G47VxO55Jps8O4nbaaweRNtDWJO
N/RuBU2UvvzVgKuKtzBNXnKF7mIEssSLnb0OyY7ANuQBwhy/FmcHWey79VLYvsKt
ZD9DzCKE0ekJLg1Pfc2bMQsiDI/O9lFB/6JeknLs7fde1b9j3+8DeL/kUDHEt4go
lG2rs44/2GqTfNdhBEU8ERIaxretstK/ms3/zLoeVYO7VQypHeeagDHH7TOfztbR
hlYX5egZRCs0VT61gp4A2BONhbSWcldFbrUa8zRXnYLPe0WZMUEcmDsVt7YXv85x
2UJtZL6jFawEr91L8bjB9bKPBQFdilJFok1o/iib1ltXhXsTItE=
=IVM1
-END PGP SIGNATURE-

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

Re: Application hanging on Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/27/18 08:49, Louis Zipes wrote:
> I looked through the log some more and I see all of the types of 
> Thread Statuses.  Blocked, Runnable, Waiting, etc..  Any in 
> particular that I should concentrate on?
The thread state doesn't always tell the whole story. Sometimes, it's
shown as RUNNABLE but it really means it's blocked. The stack trace is
more useful.

> 
> Ex. "http-bio-7005-exec-128" daemon prio=6 tid=0x26466800
> nid=0x40e4 waiting for monitor entry [0x432ae000] 
> java.lang.Thread.State: BLOCKED (on object monitor) at
> com.demantra.applicationServer.servlets.notifications.UserNotification
Helper.execute(UserNotificationHelper.java:117)
>
> 
- - waiting to lock <0x00054d652c08> (a
com.demantra.applicationServer.metaDataObjects.user.UserList)

That certainly looks like it's waiting on something. If, as Suvendu
suggests, you take more than one thread-dump in a row -- maybe 10
seconds between dumps -- and compare them, you can detect whether or
not those threads just happen to be waiting one time, or if they are
waiting forever.

> ODBC on the actual Window machine hosting Tomcat is Oracle in 
> OraClient11g_home1  (we have a 12c Oracle database) with a pool 
> timeout set to 60.  Should I be looking to turn on some tracing on 
> the driver?
60 what?

Enabling tracing is likely to generate a LOT of logging output. You
can probably discover a lot from thread dumps without changing anything.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluurbsACgkQHPApP6U8
pFgf/BAAkI/Bqy/mqcguHVaZYY1x3dOmIsGoVvIo2jKi6PUqQOdsPCwb1FR97Eoq
jtyuAiOk9bUnDUDE6l/1fNV8e2z6QHrVCGWog+3sjejpJGv4Dkfslm+wW1PsQU+/
fsd3ihtWRSyAqSNhfKuVB394yBubKuVqvHGYK6rRjyRMZ/b6JAEGOEW6/B3QBUV/
bB3TfYPZ1ih6lBrCIHaHYlFwwcVIVqqT7YJkAurdYdopqke9WY+fkgNO3i855zmV
yujcHPMjC8Y7PW9rw5VOlevYBsuxS3jf/62iXyj4fSbhUzpxrRAk0qc/dukzioFF
rgXs9VY3sJBvcmGt9bLfMiPwB9l52a/lloIiNYhitZ6ASaEKYAQqukpBwqL86NuC
8aSUNAzCt80Tr1DZZLP46KnzCfHDWocobF42locqHhe3iJ7PahfsQVVKYJ1cwyga
70qy+oBf3fzBTWq2LrA+a3TaOyOO7SVSY+NmKMS+7FNiicR18ace50PAHzjBN5eB
hOCaqeMdJh05Ip7u95VjBUqxlnc+fNli7D1rRy/jXOO/T3eqWg5nMUyrGxSVxomx
C4CU6hrc44dQeSZg2jXkgzlKOLGPmeOO+T8nPZ26Mdg2dlbbuSvSE0mydJvZzAao
Y1xmLJJDe6ciMYMkSP3JKC1bjylrRhZAZ+MC4C2iJKY564/mWQQ=
=uG5n
-END PGP SIGNATURE-

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

Re: Application hanging on Tomcat 7.0.54

[Suvendu Sekhar Mondal]

On Thu, Sep 27, 2018, 6:20 PM Louis Zipes  wrote:

> Chris,
> I looked through the log some more and I see all of the types of Thread
> Statuses.  Blocked, Runnable, Waiting, etc..  Any in particular that I
> should concentrate on?
>

Louis, can you please take multiple thread dumps(at least 3) with 5sec
interval? You need to look for threads which are not moving at all or
moving very slowly. They could be in any state. In worst case scenario you
might see some blocking or deadlock. That will give you lead on what's
going on inside the container. You can use IBM's thread dump analyzer for
that.

Ex.
> "http-bio-7005-exec-128" daemon prio=6 tid=0x26466800 nid=0x40e4
> waiting for monitor entry [0x432ae000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> com.demantra.applicationServer.servlets.notifications.UserNotificationHelper.execute(UserNotificationHelper.java:117)
> - waiting to lock <0x00054d652c08> (a
> com.demantra.applicationServer.metaDataObjects.user.UserList)
>
> ODBC on the actual Window machine hosting Tomcat is Oracle in
> OraClient11g_home1  (we have a 12c Oracle database) with a pool timeout set
> to 60.  Should I be looking to turn on some tracing on the driver?
>
> Thanks, Louis
>
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, September 26, 2018 7:30 PM
> To: users@tomcat.apache.org
> Subject: Re: Application hanging on Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Louis,
>
> On 9/26/18 15:56, Louis Zipes wrote:
> > Problem just re-occurred and so I was able to at least get a JSTACK
> > (I assume it was Tomcat since it was the Java using the most memory
> > on the machine).  Here is the reoccurring message.  I get more hits
> > on but haven't dug through all of the Google hits yet (due to
> > multi-tasking) so apologies up front if there is a simple answer to
> > this.
> >
> > "Event_Manager_1413" daemon prio=6 tid=0x24856000
> > nid=0x40c4 waiting on condition [0x42dae000]
> > java.lang.Thread.State: TIMED_WAITING (parking) at
> > sun.misc.Unsafe.park(Native Method) - parking to wait for
> > <0x0005ab45f7b8> (a
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> >
> >
> at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
> > at
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
> awaitNanos(Unknown
> > Source) at java.util.concurrent.LinkedBlockingQueue.poll(Unknown
> > Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown
> > Source) at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> > Source) at java.lang.Thread.run(Unknown Source)
>
> This thread is waiting for a task, and is essentially idle. You will
> have many of these on a non-busy system.
>
> What are the other threads doing?
>
> > Locked ownable synchronizers: - None
> >
> >> Any comments/suggestions are appreciated!
> >
> > Your most likely problem is database connection pool
> > mismanagement: connections aren't properly released and the pool
> > empties. All threads are left waiting on available database
> > connections which will never be replenished.
> >
> > I'm using the ojdbc6.jar if that is what you are referring to or is
> > there a better setting somewhere.
>
> ODBC? What is your database?
>
> - -chris
>
>
> > -Original Message- From: Christopher Schultz
> > [mailto:ch...@christopherschultz.net] Sent: Wednesday, September
> > 26, 2018 3:46 PM To: users@tomcat.apache.org Subject: Re:
> > Application hanging on Tomcat 7.0.54
> >
> > - - - external message, proceed with caution - - -
> >
> >
> > Louis,
> >
> > On 9/26/18 14:42, Louis Zipes wrote:
> >> Hi all, Tomcat 7.0.54 running on Windows 2012
> >
> >> We are running a third party application on Tomcat and today we
> >> have intermittently run in issues where the application stops
> >> working.  The big changes in our system is that we have added
> >> more end users and we are at year end so of course everyone is
> >> hitting the system hard. Even if we force a log out of all users
> >> and stop all background jobs then the application doesn't
> >> recover.
> >
> >> We see no active sessions on the database (our application is
> >> connectin

RE: Application hanging on Tomcat 7.0.54

[Louis Zipes]

Hi Guido,
Even though these hangs are critical to find, any plugin or additional code 
that I wish to put on our PRD server have to go through our SOX process so it 
can be cumbersome.  Are any of the monitoring techniques that you mention 'out 
of the box' with Tomcat 7.0.54 or JDK 1.7.  I can certainly open the JCONSOLE 
in the java bin folder  but I don't have those nice Spring Boot Add-ons 
documented in say 
https://stackoverflow.com/questions/36587023/how-to-debug-log-tomcat-jdbc-connection-pools-connections

I assume I would need something additional to do the following or not true:

>>The Tomcat JDBC Connection Pool for instance provide a MBean view for every 
>>connection with it's parameters. You may live watch the number of active, 
>>idle, ... connections (with a "well hidden" chart feature: Double-Click to 
>>expand some value representations; this here to a chart)

Thank you!

-Original Message-
From: Jäkel, Guido [mailto:g.jae...@dnb.de]
Sent: Thursday, September 27, 2018 2:29 AM
To: 'Tomcat Users List'
Subject: RE: Application hanging on Tomcat 7.0.54

- - - external message, proceed with caution - - -


Dear Louis,

I would recommend to use a tool like JVisualVM (with Plugins*) to take a look 
on this things while it's still running or have blocked. You may live watch 
things like running threads or the Java heap occupation or investigate JVM, 
Java and Tomcat parameters (and even run some actions) via JMX with 
"MBean-Explorer". You may trigger to generate a heap dump or force FullGC and 
even do CPU or Memory profiling.

The Tomcat JDBC Connection Pool for instance provide a MBean view for every 
connection with it's parameters. You may live watch the number of active, idle, 
... connections (with a "well hidden" chart feature: Double-Click to expand 
some value representations; this here to a chart)

Tomcat (i.e. Catalina) have something like a running request scoreboard, also. 
You may take and identify from that all long running or blocked requests. On 
the MBean, it's at 
"Catalina|RequestProcessor|||currentURI" and 
corresponding parameters.


(*) You would have to install some plugins inside the JVisualVM Tool, e.g. 
"Visual GC", "VisualVM Buffer Monitor", "Thread Inspector", "VisualVM BMeans"

Greetings

Guido

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

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

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

RE: Application hanging on Tomcat 7.0.54

[Louis Zipes]

Chris,
I looked through the log some more and I see all of the types of Thread 
Statuses.  Blocked, Runnable, Waiting, etc..  Any in particular that I should 
concentrate on?

Ex.
"http-bio-7005-exec-128" daemon prio=6 tid=0x26466800 nid=0x40e4 
waiting for monitor entry [0x432ae000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
com.demantra.applicationServer.servlets.notifications.UserNotificationHelper.execute(UserNotificationHelper.java:117)
- waiting to lock <0x00054d652c08> (a 
com.demantra.applicationServer.metaDataObjects.user.UserList)

ODBC on the actual Window machine hosting Tomcat is Oracle in 
OraClient11g_home1  (we have a 12c Oracle database) with a pool timeout set to 
60.  Should I be looking to turn on some tracing on the driver?

Thanks, Louis



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, September 26, 2018 7:30 PM
To: users@tomcat.apache.org
Subject: Re: Application hanging on Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/26/18 15:56, Louis Zipes wrote:
> Problem just re-occurred and so I was able to at least get a JSTACK
> (I assume it was Tomcat since it was the Java using the most memory
> on the machine).  Here is the reoccurring message.  I get more hits
> on but haven't dug through all of the Google hits yet (due to
> multi-tasking) so apologies up front if there is a simple answer to
> this.
>
> "Event_Manager_1413" daemon prio=6 tid=0x24856000
> nid=0x40c4 waiting on condition [0x42dae000]
> java.lang.Thread.State: TIMED_WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0x0005ab45f7b8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>
>
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
awaitNanos(Unknown
> Source) at java.util.concurrent.LinkedBlockingQueue.poll(Unknown
> Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown
> Source) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) at java.lang.Thread.run(Unknown Source)

This thread is waiting for a task, and is essentially idle. You will
have many of these on a non-busy system.

What are the other threads doing?

> Locked ownable synchronizers: - None
>
>> Any comments/suggestions are appreciated!
>
> Your most likely problem is database connection pool
> mismanagement: connections aren't properly released and the pool
> empties. All threads are left waiting on available database
> connections which will never be replenished.
>
> I'm using the ojdbc6.jar if that is what you are referring to or is
> there a better setting somewhere.

ODBC? What is your database?

- -chris


> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Wednesday, September
> 26, 2018 3:46 PM To: users@tomcat.apache.org Subject: Re:
> Application hanging on Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> Louis,
>
> On 9/26/18 14:42, Louis Zipes wrote:
>> Hi all, Tomcat 7.0.54 running on Windows 2012
>
>> We are running a third party application on Tomcat and today we
>> have intermittently run in issues where the application stops
>> working.  The big changes in our system is that we have added
>> more end users and we are at year end so of course everyone is
>> hitting the system hard. Even if we force a log out of all users
>> and stop all background jobs then the application doesn't
>> recover.
>
>> We see no active sessions on the database (our application is
>> connecting to an Oracle database) and I see no clear error
>> messages in either our third party application logs or the Tomcat
>> logs (ex. OutofMemory).  When we go to the Windows Task Manager
>> we did not see the machine's Memory max'd out but admittedly I
>> didn't look at the Java session to see if was reaching its Heap
>> Max.  The only thing that we noticed was that TCP connections
>> went down right after the restart.  I did open up Jconsole under
>> Java and I did force a garbage collection but that didn't seem to
>> help.
>
>> We do have an Oracle Grid Control and we did get an alert in
>> regards to Metric: [HTTP Transaction] Perceived Time per Page
>> going past thresholds but not sure if that was just an old alert
>> with and old range that was set up a long time ago or is a really
>> valid clue.Since this is PRD we

RE: Application hanging on Tomcat 7.0.54

[Jäkel , Guido]

Dear Louis,

I would recommend to use a tool like JVisualVM (with Plugins*) to take a look 
on this things while it's still running or have blocked. You may live watch 
things like running threads or the Java heap occupation or investigate JVM, 
Java and Tomcat parameters (and even run some actions) via JMX with 
"MBean-Explorer". You may trigger to generate a heap dump or force FullGC and 
even do CPU or Memory profiling.

The Tomcat JDBC Connection Pool for instance provide a MBean view for every 
connection with it's parameters. You may live watch the number of active, idle, 
... connections (with a "well hidden" chart feature: Double-Click to expand 
some value representations; this here to a chart)

Tomcat (i.e. Catalina) have something like a running request scoreboard, also. 
You may take and identify from that all long running or blocked requests. On 
the MBean, it's at 
"Catalina|RequestProcessor|||currentURI" and 
corresponding parameters.


(*) You would have to install some plugins inside the JVisualVM Tool, e.g. 
"Visual GC", "VisualVM Buffer Monitor", "Thread Inspector", "VisualVM BMeans"

Greetings

Guido

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

Re: Application hanging on Tomcat 7.0.54

[Guang Chao]

On Thu, Sep 27, 2018 at 3:56 AM Louis Zipes  wrote:

> Problem just re-occurred and so I was able to at least get a JSTACK  (I
> assume it was Tomcat since it was the Java using the most memory on the
> machine).  Here is the reoccurring message.  I get more hits on but haven't
> dug through all of the Google hits yet (due to multi-tasking) so apologies
> up front if there is a simple answer to this.
>
> "Event_Manager_1413" daemon prio=6 tid=0x24856000 nid=0x40c4
> waiting on condition [0x42dae000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0005ab45f7b8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown
> Source)
> at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
Do you lock from memory or database?  Make sure locking sequence is
consistent all across the application.  Meaning if you have

Lock A
Lock B
Lock C

You dont want another logic that locks something in another order.  E.g.

Lock B
Lock A
Lock C

Because that will cause deadlocks.



>Locked ownable synchronizers:
> - None
>
> > Any comments/suggestions are appreciated!
>
> Your most likely problem is database connection pool mismanagement:
> connections aren't properly released and the pool empties. All threads
> are left waiting on available database connections which will never be
> replenished.
>
> I'm using the ojdbc6.jar if that is what you are referring to or is there
> a better setting somewhere.
>

What db connection pool are you using? Are you letting tomcat manage it via
Context.xml and get connection via JNDI?  Or are you managing inside the
application?


>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, September 26, 2018 3:46 PM
> To: users@tomcat.apache.org
> Subject: Re: Application hanging on Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Louis,
>
> On 9/26/18 14:42, Louis Zipes wrote:
> > Hi all, Tomcat 7.0.54 running on Windows 2012
> >
> > We are running a third party application on Tomcat and today we
> > have intermittently run in issues where the application stops
> > working.  The big changes in our system is that we have added more
> > end users and we are at year end so of course everyone is hitting
> > the system hard. Even if we force a log out of all users and stop
> > all background jobs then the application doesn't recover.
> >
> > We see no active sessions on the database (our application is
> > connecting to an Oracle database) and I see no clear error messages
> > in either our third party application logs or the Tomcat logs (ex.
> > OutofMemory).  When we go to the Windows Task Manager we did not
> > see the machine's Memory max'd out but admittedly I didn't look at
> > the Java session to see if was reaching its Heap Max.  The only
> > thing that we noticed was that TCP connections went down right
> > after the restart.  I did open up Jconsole under Java and I did
> > force a garbage collection but that didn't seem to help.
> >
> > We do have an Oracle Grid Control and we did get an alert in
> > regards to Metric: [HTTP Transaction] Perceived Time per Page going
> > past thresholds but not sure if that was just an old alert with and
> > old range that was set up a long time ago or is a really valid
> > clue.Since this is PRD we had to get it back up and running so
> > all I did was increase the Tomcat Xmx Heap size and restarted.  I'm
> > not really confident that is the solution since as mentioned you
> > tend to see a clear out of memory error if it was too small.
> >
> > So a few questions:
> >
> >
> > 1) Does this sound like a known issue with this earlier version
> > of Tomcat?
>
> No.
>
> > 2) Should I turn up any logging on Tomcat and if so which
> > ones?
>
> Not yet.
>
> > 3) We didn't do a JSTACK dump while it was happening.  Would
> > that have been useful?
>
> Absolutely.
>
> > 4) Do we need to play around with MaxThreads and/or
> > MaxConnectio

Re: Application hanging on Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/26/18 15:56, Louis Zipes wrote:
> Problem just re-occurred and so I was able to at least get a JSTACK
> (I assume it was Tomcat since it was the Java using the most memory
> on the machine).  Here is the reoccurring message.  I get more hits
> on but haven't dug through all of the Google hits yet (due to
> multi-tasking) so apologies up front if there is a simple answer to
> this.
> 
> "Event_Manager_1413" daemon prio=6 tid=0x24856000
> nid=0x40c4 waiting on condition [0x42dae000] 
> java.lang.Thread.State: TIMED_WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0x0005ab45f7b8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>
> 
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
awaitNanos(Unknown
> Source) at java.util.concurrent.LinkedBlockingQueue.poll(Unknown
> Source) at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown
> Source) at
> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) at java.lang.Thread.run(Unknown Source)

This thread is waiting for a task, and is essentially idle. You will
have many of these on a non-busy system.

What are the other threads doing?

> Locked ownable synchronizers: - None
> 
>> Any comments/suggestions are appreciated!
> 
> Your most likely problem is database connection pool
> mismanagement: connections aren't properly released and the pool
> empties. All threads are left waiting on available database
> connections which will never be replenished.
> 
> I'm using the ojdbc6.jar if that is what you are referring to or is
> there a better setting somewhere.

ODBC? What is your database?

- -chris


> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Wednesday, September
> 26, 2018 3:46 PM To: users@tomcat.apache.org Subject: Re:
> Application hanging on Tomcat 7.0.54
> 
> - - - external message, proceed with caution - - -
> 
> 
> Louis,
> 
> On 9/26/18 14:42, Louis Zipes wrote:
>> Hi all, Tomcat 7.0.54 running on Windows 2012
> 
>> We are running a third party application on Tomcat and today we 
>> have intermittently run in issues where the application stops 
>> working.  The big changes in our system is that we have added
>> more end users and we are at year end so of course everyone is
>> hitting the system hard. Even if we force a log out of all users
>> and stop all background jobs then the application doesn't
>> recover.
> 
>> We see no active sessions on the database (our application is 
>> connecting to an Oracle database) and I see no clear error
>> messages in either our third party application logs or the Tomcat
>> logs (ex. OutofMemory).  When we go to the Windows Task Manager
>> we did not see the machine's Memory max'd out but admittedly I
>> didn't look at the Java session to see if was reaching its Heap
>> Max.  The only thing that we noticed was that TCP connections
>> went down right after the restart.  I did open up Jconsole under
>> Java and I did force a garbage collection but that didn't seem to
>> help.
> 
>> We do have an Oracle Grid Control and we did get an alert in 
>> regards to Metric: [HTTP Transaction] Perceived Time per Page
>> going past thresholds but not sure if that was just an old alert
>> with and old range that was set up a long time ago or is a really
>> valid clue.Since this is PRD we had to get it back up and
>> running so all I did was increase the Tomcat Xmx Heap size and
>> restarted.  I'm not really confident that is the solution since
>> as mentioned you tend to see a clear out of memory error if it
>> was too small.
> 
>> So a few questions:
> 
> 
>> 1) Does this sound like a known issue with this earlier
>> version of Tomcat?
> 
> No.
> 
>> 2) Should I turn up any logging on Tomcat and if so which 
>> ones?
> 
> Not yet.
> 
>> 3) We didn't do a JSTACK dump while it was happening.  Would 
>> that have been useful?
> 
> Absolutely.
> 
>> 4) Do we need to play around with MaxThreads and/or 
>> MaxConnections.  We do have maxThreads in our server.mxl but in
>> DEV when we turned it down to a value = 5  hoping to overwhelm
>> it nothing bad happened.
> 
> Don't change anything, yet.
> 
>> Once again, we are limited to what we could do and collect since
>> it was PRD and we needed to resta

RE: Application hanging on Tomcat 7.0.54

[Louis Zipes]

Problem just re-occurred and so I was able to at least get a JSTACK  (I assume 
it was Tomcat since it was the Java using the most memory on the machine).  
Here is the reoccurring message.  I get more hits on but haven't dug through 
all of the Google hits yet (due to multi-tasking) so apologies up front if 
there is a simple answer to this.

"Event_Manager_1413" daemon prio=6 tid=0x24856000 nid=0x40c4 waiting on 
condition [0x42dae000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0005ab45f7b8> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown
 Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

   Locked ownable synchronizers:
- None

> Any comments/suggestions are appreciated!

Your most likely problem is database connection pool mismanagement:
connections aren't properly released and the pool empties. All threads
are left waiting on available database connections which will never be
replenished.

I'm using the ojdbc6.jar if that is what you are referring to or is there a 
better setting somewhere.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, September 26, 2018 3:46 PM
To: users@tomcat.apache.org
Subject: Re: Application hanging on Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/26/18 14:42, Louis Zipes wrote:
> Hi all, Tomcat 7.0.54 running on Windows 2012
>
> We are running a third party application on Tomcat and today we
> have intermittently run in issues where the application stops
> working.  The big changes in our system is that we have added more
> end users and we are at year end so of course everyone is hitting
> the system hard. Even if we force a log out of all users and stop
> all background jobs then the application doesn't recover.
>
> We see no active sessions on the database (our application is
> connecting to an Oracle database) and I see no clear error messages
> in either our third party application logs or the Tomcat logs (ex.
> OutofMemory).  When we go to the Windows Task Manager we did not
> see the machine's Memory max'd out but admittedly I didn't look at
> the Java session to see if was reaching its Heap Max.  The only
> thing that we noticed was that TCP connections went down right
> after the restart.  I did open up Jconsole under Java and I did
> force a garbage collection but that didn't seem to help.
>
> We do have an Oracle Grid Control and we did get an alert in
> regards to Metric: [HTTP Transaction] Perceived Time per Page going
> past thresholds but not sure if that was just an old alert with and
> old range that was set up a long time ago or is a really valid
> clue.Since this is PRD we had to get it back up and running so
> all I did was increase the Tomcat Xmx Heap size and restarted.  I'm
> not really confident that is the solution since as mentioned you
> tend to see a clear out of memory error if it was too small.
>
> So a few questions:
>
>
> 1) Does this sound like a known issue with this earlier version
> of Tomcat?

No.

> 2) Should I turn up any logging on Tomcat and if so which
> ones?

Not yet.

> 3) We didn't do a JSTACK dump while it was happening.  Would
> that have been useful?

Absolutely.

> 4) Do we need to play around with MaxThreads and/or
> MaxConnections.  We do have maxThreads in our server.mxl but in DEV
> when we turned it down to a value = 5  hoping to overwhelm it
> nothing bad happened.

Don't change anything, yet.

> Once again, we are limited to what we could do and collect since it
> was PRD and we needed to restart it.  We restarted the Tomcat
> service and everything is processing fine for right now.  I will
> note that that we did have that bad Windows patch that prevented it
> from stopping and starting cleanly
> (https://stackoverflow.com/questions/51498291/tomcat-lockup-on-shutdow
n)
> but we have taken the break fix patch and the daily restarts seem
> to be fine since then.
>
> Any comments/suggestions are appreciated!

Your most likely problem is database connection pool mismanagement:
connections aren't properly released and the pool empties. All threads
are left waiting on available database connections which will never be
replenished.

- -

Re: Application hanging on Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 9/26/18 14:42, Louis Zipes wrote:
> Hi all, Tomcat 7.0.54 running on Windows 2012
> 
> We are running a third party application on Tomcat and today we
> have intermittently run in issues where the application stops
> working.  The big changes in our system is that we have added more
> end users and we are at year end so of course everyone is hitting
> the system hard. Even if we force a log out of all users and stop
> all background jobs then the application doesn't recover.
> 
> We see no active sessions on the database (our application is
> connecting to an Oracle database) and I see no clear error messages
> in either our third party application logs or the Tomcat logs (ex.
> OutofMemory).  When we go to the Windows Task Manager we did not
> see the machine's Memory max'd out but admittedly I didn't look at
> the Java session to see if was reaching its Heap Max.  The only
> thing that we noticed was that TCP connections went down right
> after the restart.  I did open up Jconsole under Java and I did
> force a garbage collection but that didn't seem to help.
> 
> We do have an Oracle Grid Control and we did get an alert in
> regards to Metric: [HTTP Transaction] Perceived Time per Page going
> past thresholds but not sure if that was just an old alert with and
> old range that was set up a long time ago or is a really valid
> clue.Since this is PRD we had to get it back up and running so
> all I did was increase the Tomcat Xmx Heap size and restarted.  I'm
> not really confident that is the solution since as mentioned you
> tend to see a clear out of memory error if it was too small.
> 
> So a few questions:
> 
> 
> 1) Does this sound like a known issue with this earlier version
> of Tomcat?

No.

> 2) Should I turn up any logging on Tomcat and if so which
> ones?

Not yet.

> 3) We didn't do a JSTACK dump while it was happening.  Would
> that have been useful?

Absolutely.

> 4) Do we need to play around with MaxThreads and/or
> MaxConnections.  We do have maxThreads in our server.mxl but in DEV
> when we turned it down to a value = 5  hoping to overwhelm it
> nothing bad happened.

Don't change anything, yet.

> Once again, we are limited to what we could do and collect since it
> was PRD and we needed to restart it.  We restarted the Tomcat
> service and everything is processing fine for right now.  I will
> note that that we did have that bad Windows patch that prevented it
> from stopping and starting cleanly
> (https://stackoverflow.com/questions/51498291/tomcat-lockup-on-shutdow
n)
> but we have taken the break fix patch and the daily restarts seem
> to be fine since then.
> 
> Any comments/suggestions are appreciated!

Your most likely problem is database connection pool mismanagement:
connections aren't properly released and the pool empties. All threads
are left waiting on available database connections which will never be
replenished.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlur4fgACgkQHPApP6U8
pFhq/RAAwZixHqbHxYdX3VCrTfvz0tnOmu7W4sbeFqhExV+M6NVL2LK1RO26eTq5
OJB2o/RheCeajWHxqiJQY4ERMTOyyqZYCsRG9L901heW2UAW122zeX7hhXDB1IMo
qIBVYQalg1j5e2Lw9MqT3ISj6U/GNA6VlirTAHGtuEBBpKXXyb6KtmOgpjHjjXS7
mTYni2iTHO/NaGrS519alFPMBnF4Wq5NzRcLewNMqj9Nbx2uu3Suu95DhJ+WIIep
DOmyy4UGHxGx2QqNUnVWMHApGGjFD4pTWIBwzcbbsL56kZDxRGsF0SsB0VR/jSMY
HdI71RgjpQFSyar1rcCTPCRP97KnUC+oaKhn+i2jBMSRxs94GEOqk4LuKNo39HKP
tXEMkYl0o/CR9QaFDjncy9M2M3/o50ooBvYTOu0SjmyZO+ab9tJpaXbnlf2ChxJI
AWbhBGmwJ6kF5FvVbmzujV7EEF2YCRMBpWo2zjNd6zWvX9OWEOXrOaHuX7iBPCga
YqEMQWyS7XWiBG7AI8+ka5x4s/oxWsbn/6pCdDXhfxl5p5jv7ajm7LbLXGut1N6a
uV5hmLLgZywF68AYe6X3GWv6mygXMBYABZxEA6klWE7HpIzvLxmxu0+vFlYR8qsb
FMAacJ/FYJ9nGRuMqG+V2Edr5U//JvrWqy4raPIvwXGtX+FsqEc=
=Zavb
-END PGP SIGNATURE-

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

Application hanging on Tomcat 7.0.54

[Louis Zipes]

Hi all,
Tomcat 7.0.54 running on Windows 2012

We are running a third party application on Tomcat and today we have 
intermittently run in issues where the application stops working.  The big 
changes in our system is that we have added more end users and we are at year 
end so of course everyone is hitting the system hard. Even if we force a log 
out of all users and stop all background jobs then the application doesn't 
recover.

We see no active sessions on the database (our application is connecting to an 
Oracle database) and I see no clear error messages in either our third party 
application logs or the Tomcat logs (ex. OutofMemory).  When we go to the 
Windows Task Manager we did not see the machine's Memory max'd out but 
admittedly I didn't look at the Java session to see if was reaching its Heap 
Max.  The only thing that we noticed was that TCP connections went down right 
after the restart.  I did open up Jconsole under Java and I did force a garbage 
collection but that didn't seem to help.

We do have an Oracle Grid Control and we did get an alert in regards to Metric: 
[HTTP Transaction] Perceived Time per Page going past thresholds but not sure 
if that was just an old alert with and old range that was set up a long time 
ago or is a really valid clue.Since this is PRD we had to get it back up 
and running so all I did was increase the Tomcat Xmx Heap size and restarted.  
I'm not really confident that is the solution since as mentioned you tend to 
see a clear out of memory error if it was too small.

So a few questions:


1) Does this sound like a known issue with this earlier version of Tomcat?

2) Should I turn up any logging on Tomcat and if so which ones?

3) We didn't do a JSTACK dump while it was happening.  Would that have been 
useful?

4) Do we need to play around with MaxThreads and/or MaxConnections.  We do 
have maxThreads in our server.mxl but in DEV when we turned it down to a value 
= 5  hoping to overwhelm it nothing bad happened.

Once again, we are limited to what we could do and collect since it was PRD and 
we needed to restart it.  We restarted the Tomcat service and everything is 
processing fine for right now.  I will note that that we did have that bad 
Windows patch that prevented it from stopping and starting cleanly  
(https://stackoverflow.com/questions/51498291/tomcat-lockup-on-shutdown) but we 
have taken the break fix patch and the daily restarts seem to be fine since 
then.

Any comments/suggestions are appreciated!

Thanks, Louis




LOUIS ZIPES
SOFTWARE DEVELOPER ANALYST IV
O: 781-418-3257
louis.zi...@keurig.com<mailto:louis.zi...@keurig.com>
Keurig Dr Pepper
Visit us at www.KeurigDrPepper.com<http://www.keurigdrpepper.com/>


---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/15/18 7:58 AM, Louis Zipes wrote:
> One correction.  I meant to say that I'm using 8.5 (put my zero in 
> the wrong place)

Glad you are upgrading. 8.5.x is mature enough at this point that
there should be a remediation for any incompatibility you may find
with previous versions of Tomcat.

Moving to 9.0 may require some changes to the application because of
stricter-adherence to various standards and the desire of the Tomcat
team to finally move-on from backward-compatible hacks, etc. for those
things.

I would recommend that as soon as you get your application running
properly under Tomcat 8.5.x you immediately begin testing it with
Tomcat 9.0.x in order to future-proof said application. Any changes
you make to fix issues with Tomcat 9.0.x /should/ be equally valid in
Tomcat 8.5.x, but you'll also be ready for another upgrade in a year
or so (or whatever your "major container upgrade" schedule turns out
to be).

FWIW, at $work we are only upgrading to 8.5.x starting this fall.

> and yes, looking at the GUI for the Tomcat8w in the 'Start' and 
> 'Stop' tabs it does indeed say JVM and it runs with no 32 bit
> error message like the packaged Tomcat 7.0.54 that came packaged
> with my third party app.
So the switch from "java" -> "jvm" is very likely the only relevant
change, here.

> Thanks again.  There are a lot of articles on Stack Exchange that 
> would benefit from this additional information!
Well, now you are an expert and you can enlighten everybody :)

- -chris

> 
> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Tuesday, August 14,
> 2018 6:41 PM To: users@tomcat.apache.org Subject: Re: Question
> about setting CATALINA_OPTS when starting Tomcat using a Windows
> Service in Tomcat 7.0.54
> 
> - - - external message, proceed with caution - - -
> 
> 
> Louis,
> 
> On 8/14/18 3:28 PM, Louis Zipes wrote:
>> Hi all, Just wanted to circle back.  There was an early comment 
>> (maybe even in the first response to my question/problem) where 
>> someone mentioned that my set up (Running Tomcat as a Windows 
>> Service and  putting the JMX parameters directly in the 
>> Tomcat7.0.54 GUI in the Java tab) SHOULD work and should startup 
>> and shutdown gracefully  BUT that if it doesn't then try one of
>> the of the later versions of Tomcat.
> 
>> I did finally get a chance to try Tomcat 8.0.5X and it does seem
>> to work with no other configuration changes.  I can access JMX 
>> (JConsole) and start and shut down the Windows Service running 
>> Tomcat with no issues.   Although, now my problem is that my
>> third party application, that is running  doesn't work,  but that
>> is not a problem for this mailing list.
> 
>> So I think we can say that in the end the upgrade to a higher 
>> version resolved the issue.   Thank you to all that contributed 
>> input!
> 
> It's very possible that, if you used the service-installer, it
> simply created a new service that uses the "jvm" launch-strategy.
> 
> I'd be interested to see if that's the case.
> 
> Before you spend a lot of time tracking-down the application 
> incompatabilities with 8.0.x, you might want to upgrade to 9.0.x
> or 8.5.x and start there. Tomcat 8.0.x has reached EOL so it's
> probably a waste of your time to test against it.
> 
> Hope that helps, -chris
> 
>> -Original Message----- From: André Warnier (tomcat) 
>> [mailto:a...@ice-sa.com] Sent: Thursday, August 09, 2018 12:40 PM
>> To: users@tomcat.apache.org Subject: Re: Question about setting 
>> CATALINA_OPTS when starting Tomcat using a Windows Service in 
>> Tomcat 7.0.54
> 
>> - - - external message, proceed with caution - - -
> 
> 
>> Maybe it is time here to quote Arthur Clarke's 3rd law : "Any 
>> sufficiently advanced technology is indistinguishable from
>> magic" (See :
>> https://en.wikipedia.org/wiki/Clarke%27s_three_laws)
> 
>> The process by which Tomcat is started and/or stopped - 
>> particularly under Windows and as a Service - is not very clear
>> in the on-line documentation. Neither is it it very easy to write
>> a comprehensive and accurate documentation, because the thing
>> has gotten to a point where, for mere mortals, it is really
>> quite complicated. (Have a look at bin/catalina.bat to get an
>> idea).
> 
>> So let me give you some overall pointers (some of them quite
>> basic, I apologise), and maybe in there somewhere, you'll find
>> wat you are missing to complete the picture and do what you want
>> to do.
> 
>> 1) Tomcat is a compiled java applica

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

One correction.  I meant to say that I'm using 8.5 (put my zero in the wrong 
place) and yes, looking at the GUI for the Tomcat8w in the 'Start' and 'Stop' 
tabs it does indeed say JVM and it runs with no 32 bit error message like the 
packaged Tomcat 7.0.54 that came packaged with my third party app.

Thanks again.  There are a lot of articles on Stack Exchange that would benefit 
from this additional information!

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, August 14, 2018 6:41 PM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/14/18 3:28 PM, Louis Zipes wrote:
> Hi all, Just wanted to circle back.  There was an early comment
> (maybe even in the first response to my question/problem) where
> someone mentioned that my set up (Running Tomcat as a Windows
> Service and  putting the JMX parameters directly in the
> Tomcat7.0.54 GUI in the Java tab) SHOULD work and should startup
> and shutdown gracefully  BUT that if it doesn't then try one of the
> of the later versions of Tomcat.
>
> I did finally get a chance to try Tomcat 8.0.5X and it does seem to
> work with no other configuration changes.  I can access JMX
> (JConsole) and start and shut down the Windows Service running
> Tomcat with no issues.   Although, now my problem is that my third
> party application, that is running  doesn't work,  but that is not
> a problem for this mailing list.
>
> So I think we can say that in the end the upgrade to a higher
> version resolved the issue.   Thank you to all that contributed
> input!

It's very possible that, if you used the service-installer, it simply
created a new service that uses the "jvm" launch-strategy.

I'd be interested to see if that's the case.

Before you spend a lot of time tracking-down the application
incompatabilities with 8.0.x, you might want to upgrade to 9.0.x or
8.5.x and start there. Tomcat 8.0.x has reached EOL so it's probably a
waste of your time to test against it.

Hope that helps,
- -chris

> -Original Message- From: André Warnier (tomcat)
> [mailto:a...@ice-sa.com] Sent: Thursday, August 09, 2018 12:40 PM To:
> users@tomcat.apache.org Subject: Re: Question about setting
> CATALINA_OPTS when starting Tomcat using a Windows Service in
> Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> Maybe it is time here to quote Arthur Clarke's 3rd law : "Any
> sufficiently advanced technology is indistinguishable from magic"
> (See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws)
>
> The process by which Tomcat is started and/or stopped -
> particularly under Windows and as a Service - is not very clear in
> the on-line documentation. Neither is it it very easy to write a
> comprehensive and accurate documentation, because the thing has
> gotten to a point where, for mere mortals, it is really quite
> complicated. (Have a look at bin/catalina.bat to get an idea).
>
> So let me give you some overall pointers (some of them quite basic,
> I apologise), and maybe in there somewhere, you'll find wat you are
> missing to complete the picture and do what you want to do.
>
> 1) Tomcat is a compiled java application, in java bytecode.  To run
> this bytecode, you need a JVM. The JVM is machine-executable code,
> so to run tomcat, you run a JVM and tell it to run the tomcat
> bytecode. 2) the java JVM for Windows is not very good at running
> as a Windows Service (it does not handle the appropriate Windows
> "signals" etc.). To solve this, when you want to run tomcat as a
> Windows Service (or rather - see above - run the JVM as a Windows
> Service), you actually run a specialised "wrapper program" which
> does work well as a Windows Service, and you ask this wrapper to
> start the JVM which runs tomcat. To make matters a bit more
> confusing (or maybe, for some, clearer), this generic "Windows
> Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the
> tomcat version, so for tomcat 9, the program is called
> tomcat9.exe). 3) the wrapper program, when it starts the JVM, has
> to know which command-line switches it should pass to it.  For the
> Windows Service flavor of tomcat, these parameters are stored in a
> number of special keys in the Windows Registry, and that is where
> the wrapper picks them up, before starting the JVM. 4) To make it
> easier to set and edit these JVM command-line parameters, tomcat
> provides another Windows executable program - a specialised GUI
> Registry Editor - which is also renamed according to the tomcat
>

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/14/18 3:28 PM, Louis Zipes wrote:
> Hi all, Just wanted to circle back.  There was an early comment
> (maybe even in the first response to my question/problem) where
> someone mentioned that my set up (Running Tomcat as a Windows
> Service and  putting the JMX parameters directly in the
> Tomcat7.0.54 GUI in the Java tab) SHOULD work and should startup
> and shutdown gracefully  BUT that if it doesn't then try one of the
> of the later versions of Tomcat.
> 
> I did finally get a chance to try Tomcat 8.0.5X and it does seem to
> work with no other configuration changes.  I can access JMX
> (JConsole) and start and shut down the Windows Service running
> Tomcat with no issues.   Although, now my problem is that my third
> party application, that is running  doesn't work,  but that is not
> a problem for this mailing list.
> 
> So I think we can say that in the end the upgrade to a higher
> version resolved the issue.   Thank you to all that contributed
> input!

It's very possible that, if you used the service-installer, it simply
created a new service that uses the "jvm" launch-strategy.

I'd be interested to see if that's the case.

Before you spend a lot of time tracking-down the application
incompatabilities with 8.0.x, you might want to upgrade to 9.0.x or
8.5.x and start there. Tomcat 8.0.x has reached EOL so it's probably a
waste of your time to test against it.

Hope that helps,
- -chris

> -Original Message- From: André Warnier (tomcat)
> [mailto:a...@ice-sa.com] Sent: Thursday, August 09, 2018 12:40 PM To:
> users@tomcat.apache.org Subject: Re: Question about setting
> CATALINA_OPTS when starting Tomcat using a Windows Service in
> Tomcat 7.0.54
> 
> - - - external message, proceed with caution - - -
> 
> 
> Maybe it is time here to quote Arthur Clarke's 3rd law : "Any
> sufficiently advanced technology is indistinguishable from magic" 
> (See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws)
> 
> The process by which Tomcat is started and/or stopped -
> particularly under Windows and as a Service - is not very clear in
> the on-line documentation. Neither is it it very easy to write a
> comprehensive and accurate documentation, because the thing has
> gotten to a point where, for mere mortals, it is really quite
> complicated. (Have a look at bin/catalina.bat to get an idea).
> 
> So let me give you some overall pointers (some of them quite basic,
> I apologise), and maybe in there somewhere, you'll find wat you are
> missing to complete the picture and do what you want to do.
> 
> 1) Tomcat is a compiled java application, in java bytecode.  To run
> this bytecode, you need a JVM. The JVM is machine-executable code,
> so to run tomcat, you run a JVM and tell it to run the tomcat
> bytecode. 2) the java JVM for Windows is not very good at running
> as a Windows Service (it does not handle the appropriate Windows
> "signals" etc.). To solve this, when you want to run tomcat as a
> Windows Service (or rather - see above - run the JVM as a Windows
> Service), you actually run a specialised "wrapper program" which
> does work well as a Windows Service, and you ask this wrapper to
> start the JVM which runs tomcat. To make matters a bit more
> confusing (or maybe, for some, clearer), this generic "Windows 
> Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the
> tomcat version, so for tomcat 9, the program is called
> tomcat9.exe). 3) the wrapper program, when it starts the JVM, has
> to know which command-line switches it should pass to it.  For the
> Windows Service flavor of tomcat, these parameters are stored in a
> number of special keys in the Windows Registry, and that is where
> the wrapper picks them up, before starting the JVM. 4) To make it
> easier to set and edit these JVM command-line parameters, tomcat
> provides another Windows executable program - a specialised GUI
> Registry Editor - which is also renamed according to the tomcat
> version, as tomcatVw.exe (where V is the tomcat version, so for
> tomcat 9 it would be tomcat9w.exe).
> 
> 5) as a separate bit of knowledge, I would suppose that everyone
> knows that on any given host, a given TCP listening port can only
> be opened by one process at a time. If a second process tries to
> open a port which is already opened by a first process, it will get
> an error of the kind "port already in use", and most probably the
> second process will then exit (non-gracefully).
> 
> 6) in the tomcat conf/server.xml file, there is a tag :  port="8005" shutdown="SHUTDOWN"> This provides a clue as to how one
> actually *stops* tomcat : one opens a 

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Hi all,
Just wanted to circle back.  There was an early comment (maybe even in the 
first response to my question/problem) where someone mentioned that my set up 
(Running Tomcat as a Windows Service and  putting the JMX parameters directly 
in the Tomcat7.0.54 GUI in the Java tab) SHOULD work and should startup and 
shutdown gracefully  BUT that if it doesn't then try one of the of the later 
versions of Tomcat.

I did finally get a chance to try Tomcat 8.0.5X and it does seem to work with 
no other configuration changes.  I can access JMX (JConsole) and start and shut 
down the Windows Service running Tomcat with no issues.   Although, now my 
problem is that my third party application, that is running  doesn't work,  but 
that is not a problem for this mailing list.

So I think we can say that in the end the upgrade to a higher version resolved 
the issue.   Thank you to all that contributed input!

- Louis

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Thursday, August 09, 2018 12:40 PM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


Maybe it is time here to quote Arthur Clarke's 3rd law :
"Any sufficiently advanced technology is indistinguishable from magic"
(See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws)

The process by which Tomcat is started and/or stopped - particularly under 
Windows and as
a Service - is not very clear in the on-line documentation.
Neither is it it very easy to write a comprehensive and accurate documentation, 
because
the thing has gotten to a point where, for mere mortals, it is really quite 
complicated.
(Have a look at bin/catalina.bat to get an idea).

So let me give you some overall pointers (some of them quite basic, I 
apologise), and
maybe in there somewhere, you'll find wat you are missing to complete the 
picture and do
what you want to do.

1) Tomcat is a compiled java application, in java bytecode.  To run this 
bytecode, you
need a JVM. The JVM is machine-executable code, so to run tomcat, you run a JVM 
and tell
it to run the tomcat bytecode.
2) the java JVM for Windows is not very good at running as a Windows Service 
(it does not
handle the appropriate Windows "signals" etc.). To solve this, when you want to 
run tomcat
as a Windows Service (or rather - see above - run the JVM as a Windows 
Service), you
actually run a specialised "wrapper program" which does work well as a Windows 
Service,
and you ask this wrapper to start the JVM which runs tomcat.
To make matters a bit more confusing (or maybe, for some, clearer), this 
generic "Windows
Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the tomcat 
version, so for
tomcat 9, the program is called tomcat9.exe).
3) the wrapper program, when it starts the JVM, has to know which command-line 
switches it
should pass to it.  For the Windows Service flavor of tomcat, these parameters 
are stored
in a number of special keys in the Windows Registry, and that is where the 
wrapper picks
them up, before starting the JVM.
4) To make it easier to set and edit these JVM command-line parameters, tomcat 
provides
another Windows executable program - a specialised GUI Registry Editor - which 
is also
renamed according to the tomcat version, as tomcatVw.exe (where V is the tomcat 
version,
so for tomcat 9 it would be tomcat9w.exe).

5) as a separate bit of knowledge, I would suppose that everyone knows that on 
any given
host, a given TCP listening port can only be opened by one process at a time. 
If a second
process tries to open a port which is already opened by a first process, it 
will get an
error of the kind "port already in use", and most probably the second process 
will then
exit (non-gracefully).

6) in the tomcat conf/server.xml file, there is a tag :

This provides a clue as to how one actually *stops* tomcat : one opens a TCP 
connection to
locahost port 8005 (on which tomcat listens), then sends the string "SHUTDOWN" 
on that
connection. This causes tomcat to shutdown gracefully, at the end of which it 
does a
"system.exit()" which shuts down the JVM that runs it.
And this in turn causes the JVM wrapper program to tell Windows that the tomcat 
Service is
shutting down, before itself exiting. And thus is all well and tidy in the 
Windows Service
world.

7) a helpful feature of tomcat, is that it itself provides code to connect to 
localhost
port 8005 and send that shutdown string, so that one does not have to write its 
own
separate program to do that.
The bit that is a bit confusing about this feature however, is that in order to 
use that
code, one of course needs to start up another separate instance of tomcat, just 
to run
that code and actually stop the "real" running tomcat.
And of course running a separate i

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Slotting this Interim update before we started using [OT] so not sure if this 
is the right spot.

>> You see the error you are see because you are using Java mode. Switch
>> to jvm mode and all should be well.

I did try with JVM mode but now I'm getting a Client Version mismatch.  I'm 
going to try to download the 64 bit version of Tomcat BUT I'm using the Tomcat 
that came pre-packaged with my application package  so I wonder if there is a 
reason why they loaded it with 32 bit

Error message on start up

[2018-08-09 08:37:59] [info]  [ 4304] Stopping service...
[2018-08-09 08:37:59] [error] [ 4304] %1 is not a valid Win32 application.
[2018-08-09 08:37:59] [error] [ 4304] Failed creating java C:\Program 
Files\Java\jdk1.7.0_80\jre\bin\server\jvm.dll
[2018-08-09 08:37:59] [error] [ 4304] %1 is not a valid Win32 application.

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: Thursday, August 09, 2018 12:40 PM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


Maybe it is time here to quote Arthur Clarke's 3rd law :
"Any sufficiently advanced technology is indistinguishable from magic"
(See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws)

The process by which Tomcat is started and/or stopped - particularly under 
Windows and as
a Service - is not very clear in the on-line documentation.
Neither is it it very easy to write a comprehensive and accurate documentation, 
because
the thing has gotten to a point where, for mere mortals, it is really quite 
complicated.
(Have a look at bin/catalina.bat to get an idea).

So let me give you some overall pointers (some of them quite basic, I 
apologise), and
maybe in there somewhere, you'll find wat you are missing to complete the 
picture and do
what you want to do.

1) Tomcat is a compiled java application, in java bytecode.  To run this 
bytecode, you
need a JVM. The JVM is machine-executable code, so to run tomcat, you run a JVM 
and tell
it to run the tomcat bytecode.
2) the java JVM for Windows is not very good at running as a Windows Service 
(it does not
handle the appropriate Windows "signals" etc.). To solve this, when you want to 
run tomcat
as a Windows Service (or rather - see above - run the JVM as a Windows 
Service), you
actually run a specialised "wrapper program" which does work well as a Windows 
Service,
and you ask this wrapper to start the JVM which runs tomcat.
To make matters a bit more confusing (or maybe, for some, clearer), this 
generic "Windows
Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the tomcat 
version, so for
tomcat 9, the program is called tomcat9.exe).
3) the wrapper program, when it starts the JVM, has to know which command-line 
switches it
should pass to it.  For the Windows Service flavor of tomcat, these parameters 
are stored
in a number of special keys in the Windows Registry, and that is where the 
wrapper picks
them up, before starting the JVM.
4) To make it easier to set and edit these JVM command-line parameters, tomcat 
provides
another Windows executable program - a specialised GUI Registry Editor - which 
is also
renamed according to the tomcat version, as tomcatVw.exe (where V is the tomcat 
version,
so for tomcat 9 it would be tomcat9w.exe).

5) as a separate bit of knowledge, I would suppose that everyone knows that on 
any given
host, a given TCP listening port can only be opened by one process at a time. 
If a second
process tries to open a port which is already opened by a first process, it 
will get an
error of the kind "port already in use", and most probably the second process 
will then
exit (non-gracefully).

6) in the tomcat conf/server.xml file, there is a tag :

This provides a clue as to how one actually *stops* tomcat : one opens a TCP 
connection to
locahost port 8005 (on which tomcat listens), then sends the string "SHUTDOWN" 
on that
connection. This causes tomcat to shutdown gracefully, at the end of which it 
does a
"system.exit()" which shuts down the JVM that runs it.
And this in turn causes the JVM wrapper program to tell Windows that the tomcat 
Service is
shutting down, before itself exiting. And thus is all well and tidy in the 
Windows Service
world.

7) a helpful feature of tomcat, is that it itself provides code to connect to 
localhost
port 8005 and send that shutdown string, so that one does not have to write its 
own
separate program to do that.
The bit that is a bit confusing about this feature however, is that in order to 
use that
code, one of course needs to start up another separate instance of tomcat, just 
to run
that code and actually stop the "real" running tomcat.
And of course running a separate instance of tomcat actually means running a 
separate
instance of 

Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 8/9/18 6:22 PM, André Warnier (tomcat) wrote:
>> The problem remains though : Under Windows, a Service has a
>> single executable, which Windows starts when starting the
>> Service, and then waits for that executable to send back a
>> message indicating that the Service has properly started. 
>> Similarly, to stop the Service, Windows sends a message "please
>> stop" to that running executable, and waits for the executable to
>> acknowedge that it is stopping. With Tomcat, this executable is
>> "tomcatV.exe" (the renamed Apache Common wrapper). To my
>> knowledge, there is no provision in Windows for starting a
>> service by running one executable, and stopping it using
>> *another* executable.

This is true, but tomcatV.exe actually handles this correctly. But
there is a difference between "java" and "jvm" modes. Go back and read
Mark's message about it carefully, again; I had to do so myself before
I understood why it will work by switching modes.

>> So your suggestion above is indeed not usable for the Windows
>> Service context.

Correct. Even a self-contained "Tomcat-stopping win32 program"
wouldn't work in a Windows-service-context.

>> And thus, for stopping the Tomcat Service, the user is stuck
>> with tomcatV.exe, which uses the *same* JVM command-line
>> parameters whether it is to start or to stop tomcat.

Unless "jvm" mode is used.

>> A solution would be to add a separate options box to the
>> "Startup" and "Shutdown" tabs of the tomcat9w.exe dialog for
>> "additional JVM options at start" and "additional JVM options at
>> stop" (and of course all the associated plumbing in the wrapper
>> code). But I guess that this would go in the category of
>> "enhancement request".

Correct, but "jvm mode" should work with existing features.

>> I've seen Mark's previous answer, which seems to indicate that
>> there is actually another way, but I must confess that I did not
>> understand it.

If you use "java" mode, this is what happens:

Service launch:
1. Windows Service Manager invokes tomcatV.exe
2. tomcatV.exe reads registry for config
3. tomcatV.exe invokes "java [params] o.a.c.Bootstrap start"

Service shutdown:
1. Windows Service Manager invokes tomcatV.exe
2. tomcatV.exe reads registry for config
3. tomcatV.exe invokes "java [params] o.a.c.Bootstrap stop"

You see the problem because "[params]" are the same in both cases, and
the JMX port (and any other Java-specified ports, such as a profiling
agent, etc.) conflict.

If you use "jvm" mode, this is what happens:

Service launch:
1. Windows Service Manager invokes tomcatV.exe
2. tomcatV.exe reads registry for config
3. tomcatV.exe launches an in-process JVM with "[params]" and then
calls o.a.c.Bootstrap.main("start")

Service shutdown:
1. Windows Service Manager invokes tomcatV.exe
2. tomcatV.exe reads registry for config
3. tomcatV.exe calls o.a.c.Bootstrap.main("stop") on the
already-running in-process JVM

In the "jvm mode" case, only one JVM is launched for the start/stop
sequence instead of one JVM for each of start, stop.

So he port-conflict is avoided, and the system is more efficient
(launching a JVM is pretty expensive).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlttvsEACgkQHPApP6U8
pFgnThAAvZXka+FYgjiJYM+RfYoBOuAwsym44WyToFo7JAAXhMzzIDM8CY6ZceOs
ZojWLcCAYCzDjiBhuEh2KdUfnaelrUPG0451jj0cBqNe6kkSXZ4soS27t+uyUSKG
SPx8u+j5CtHsvEhC5TwwBAVe9dLZ2kD4s8y14R7o3A/sbwim7kgKOw4cA7BdrrmT
0jK4+ce6d1vv5edTkU84HnjNx4y96jbr4/uKBOa+qPYgHeYct84/ADKXn4dZcce6
lliiPu6kGWOvpu04kqqSqwVY3KrcT91q5aXJ8UYyiSbOr+cj+HP4GhDy+Dxdnoze
Kzi+9V7bqkSa9g995kED4v3mRTfg76dRjuxnHbw1hGThkCO5Pi3MJQOjaUfs1XMo
EgT/OLvRqPQlYvi3S1r36QzDBCKh1LVyDntSMIiJn0ilthrwHJfhiPRH6n9jb7Gp
egP3tb+s6LJp15uA8noyTBTBVlOwFE8Kw8XXyEtwOE7cW0QJQXpJSkbatJqsHB94
v10a37SuagkkzaJugGfey6Vcg9oGjWWjENIxB7yK2dZHm1+cm263/9Qmi37WVj4d
KWMdghzoazdOxvK5ntFi2hOs0kdQ3v+EgxWQR9FKJz73piIvsIleVE3v4B49W5oh
nTM/eJtOwJcoYdLG3ljNpND61BvpjuFCm9JUbWizFgJMu6OjY2k=
=F5zk
-END PGP SIGNATURE-

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

Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[tomcat]

On 09.08.2018 20:05, Louis Zipes wrote:

Oh! André, if you aren't using JMX in production, you are missing-out
on a wealth of monitoring information about your JVM(s).


OK, fine, I accept that. I was just saying "IF you don't need it in production".
So, scratch the idea of running Tomcat in a console also.
You want to run Tomcat as a Service AND use JMX.
That thus leaves the problem that there is only one set of JVM command-line 
parameters.



But rather than using the JMX protocol, I would recommend using
Tomcat's JMXProxyServlet -- a part of the Manager application. That
allows you to make JMX queries over HTTP, and you don't have to
mess-around with Java's JMX-protocol configuration and ugly (and
lacking) authentication capabilities.


Just this moment we had a mystery 'hang' with my Tomcat service in PRD that 
required a Service Restart.  If I had JMX enabled then I might have been able 
to get some more information.  We just onboarded a bunch of new users but the 
Tomcat logs themselves don't clearly show memory issues so would have been nice 
to have that extra layer of logging that JMX would have given me to see if I 
could have figured it out.


Still working on the other suggestions that people have given over the last 24 
hours on trying to get it to working.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, August 09, 2018 1:57 PM
To: users@tomcat.apache.org
Subject: Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat 
using a Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 8/9/18 12:39 PM, André Warnier (tomcat) wrote:

7) a helpful feature of tomcat, is that it itself provides code to
connect to localhost port 8005 and send that shutdown string, so
that one does not have to write its own separate program to do
that. The bit that is a bit confusing about this feature however,
is that in order to use that code, one of course needs to start up
another separate instance of tomcat, just to run that code and
actually stop the "real" running tomcat.


This should really not be a requirement. Launching a JVM just to parse
some XML and send a single TCP packet is kind of wasteful. The problem
is that Tomcat can't rely on any particular utility programs being
installed on the server in order to do something possibly more efficient
.




I could whip-up something using grep, curl, and plain-old sh for
example that would work on most *NIX systems, but windows users
wouldn't benefit from that kind of thing.



Understood also.
The problem remains though :
Under Windows, a Service has a single executable, which Windows starts when starting the 
Service, and then waits for that executable to send back a message indicating that the 
Service has properly started.
Similarly, to stop the Service, Windows sends a message "please stop" to that running 
executable, and waits for the executable to acknowedge that it is stopping.

With Tomcat, this executable is "tomcatV.exe" (the renamed Apache Common 
wrapper).
To my knowledge, there is no provision in Windows for starting a service by running one 
executable, and stopping it using *another* executable.

So your suggestion above is indeed not usable for the Windows Service context.
And thus, for stopping the Tomcat Service, the user is stuck with tomcatV.exe, which uses 
the *same* JVM command-line parameters whether it is to start or to stop tomcat.
And that's where the problem lies currently, for the OP : if these JVM parameters contain 
the stanza needed to open the JMX port, then the "stop" command will try again to open the 
same JMX port, and fail.


Under Linux, and under Windows when running tomcat in a console, there is a 
distinction
between JAVA_OPTS (which are always used in the JVM command-line), and CATALINA_OPTS 
(which are only added when starting tomcat). So you could put the JMX parameters in 
CATALINA_OPTS, and the JVM would only open the JMX port when starting tomcat.
But, currently, when running tomcat as a Windows Service, there is apparently no way to 
provide JVM command-line parameters which are used only at start.


A solution would be to add a separate options box to the "Startup" and "Shutdown" tabs of 
the tomcat9w.exe dialog for "additional JVM options at start" and "additional JVM options 
at stop" (and of course all the associated plumbing in the wrapper code). But I guess that 
this would go in the category of "enhancement request".


I've seen Mark's previous answer, which seems to indicate that there is actually another 
way, but I must confess that I did not understand it.




I was very surprised to find out that Tomcat's Windows service-runner
doesn't have separate "launch parameters" versus "stop parameters"
(i.e. the equivalent of C

RE: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Oh! André, if you aren't using JMX in production, you are missing-out
on a wealth of monitoring information about your JVM(s).

But rather than using the JMX protocol, I would recommend using
Tomcat's JMXProxyServlet -- a part of the Manager application. That
allows you to make JMX queries over HTTP, and you don't have to
mess-around with Java's JMX-protocol configuration and ugly (and
lacking) authentication capabilities.

>> Just this moment we had a mystery 'hang' with my Tomcat service in PRD that 
>> required a Service Restart.  If I had JMX enabled then I might have been 
>> able to get some more information.  We just onboarded a bunch of new users 
>> but the Tomcat logs themselves don't clearly show memory issues so would 
>> have been nice to have that extra layer of logging that JMX would have given 
>> me to see if I could have figured it out.

Still working on the other suggestions that people have given over the last 24 
hours on trying to get it to working.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, August 09, 2018 1:57 PM
To: users@tomcat.apache.org
Subject: Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat 
using a Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 8/9/18 12:39 PM, André Warnier (tomcat) wrote:
> 7) a helpful feature of tomcat, is that it itself provides code to
> connect to localhost port 8005 and send that shutdown string, so
> that one does not have to write its own separate program to do
> that. The bit that is a bit confusing about this feature however,
> is that in order to use that code, one of course needs to start up
> another separate instance of tomcat, just to run that code and
> actually stop the "real" running tomcat.

This should really not be a requirement. Launching a JVM just to parse
some XML and send a single TCP packet is kind of wasteful. The problem
is that Tomcat can't rely on any particular utility programs being
installed on the server in order to do something possibly more efficient
.

I could whip-up something using grep, curl, and plain-old sh for
example that would work on most *NIX systems, but windows users
wouldn't benefit from that kind of thing.

I was very surprised to find out that Tomcat's Windows service-runner
doesn't have separate "launch parameters" versus "stop parameters"
(i.e. the equivalent of CATALINA_OPTS versus JAVA_OPTS for the
script-based service-management). I guess that's just a (another) pill
you'll have to swallow if you want to run on Windows.

> Of course, one could also wonder if you really need JMX when you
> run tomcat in production mode.  If this is only for testing, you
> could run tomcat in a console, where you would not have the same
> issue (because you would not have the wrapper with its
> single-minded preset JVM options).

Oh! André, if you aren't using JMX in production, you are missing-out
on a wealth of monitoring information about your JVM(s).

But rather than using the JMX protocol, I would recommend using
Tomcat's JMXProxyServlet -- a part of the Manager application. That
allows you to make JMX queries over HTTP, and you don't have to
mess-around with Java's JMX-protocol configuration and ugly (and
lacking) authentication capabilities.

> (Or you could switch to Linux ;-))

A wise choice IMHO, if you have the expertise to manage it. I wouldn't
recommend that a Windows shop just switch to Linux any time soon. But
if you have people very familiar with *NIX deployments, I would
recommend keeping Windows on desktops and leave the servers running
some kind of *NIX.

- -chris

> On 09.08.2018 02:06, Daniel Savard wrote:
>> Le mer. 8 août 2018 à 12:08, Louis Zipes  a
>> écrit :
>>
>>>
>>> Hi Calder, I can successfully start up as a Windows service and
>>> get JMX working BUT my problem is that Service doesn't stop
>>> cleanly (just repeating that problem in case it wasn't made
>>> clear).  It says the PORT is already in use which led me to try
>>> to use Catalina_Opts as per the suggestions on the internet.
>>>
>>> Port already in use: 8008; nested exception is:
>>> java.net.BindException: Address already in use: JVM_Bind
>>>
>>> If you were able to get JMX working and you can start AND stop
>>> the Tomcat service cleanly, do you mind sharing me your
>>> 'scrubbed'  Java tab contents as I can seem to get the right
>>> combination to get it to Start and Stop the service.
>>>
>>> Thanks, Louis
>>>
>>>
>>>
>> Louis,
>>
>> I believe you need to understand a bit more how things are
>> working with Java and the JVM. T

Re: [OT] Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 8/9/18 12:39 PM, André Warnier (tomcat) wrote:
> 7) a helpful feature of tomcat, is that it itself provides code to 
> connect to localhost port 8005 and send that shutdown string, so
> that one does not have to write its own separate program to do
> that. The bit that is a bit confusing about this feature however,
> is that in order to use that code, one of course needs to start up
> another separate instance of tomcat, just to run that code and
> actually stop the "real" running tomcat.

This should really not be a requirement. Launching a JVM just to parse
some XML and send a single TCP packet is kind of wasteful. The problem
is that Tomcat can't rely on any particular utility programs being
installed on the server in order to do something possibly more efficient
.

I could whip-up something using grep, curl, and plain-old sh for
example that would work on most *NIX systems, but windows users
wouldn't benefit from that kind of thing.

I was very surprised to find out that Tomcat's Windows service-runner
doesn't have separate "launch parameters" versus "stop parameters"
(i.e. the equivalent of CATALINA_OPTS versus JAVA_OPTS for the
script-based service-management). I guess that's just a (another) pill
you'll have to swallow if you want to run on Windows.

> Of course, one could also wonder if you really need JMX when you
> run tomcat in production mode.  If this is only for testing, you
> could run tomcat in a console, where you would not have the same
> issue (because you would not have the wrapper with its
> single-minded preset JVM options).

Oh! André, if you aren't using JMX in production, you are missing-out
on a wealth of monitoring information about your JVM(s).

But rather than using the JMX protocol, I would recommend using
Tomcat's JMXProxyServlet -- a part of the Manager application. That
allows you to make JMX queries over HTTP, and you don't have to
mess-around with Java's JMX-protocol configuration and ugly (and
lacking) authentication capabilities.

> (Or you could switch to Linux ;-))

A wise choice IMHO, if you have the expertise to manage it. I wouldn't
recommend that a Windows shop just switch to Linux any time soon. But
if you have people very familiar with *NIX deployments, I would
recommend keeping Windows on desktops and leave the servers running
some kind of *NIX.

- -chris

> On 09.08.2018 02:06, Daniel Savard wrote:
>> Le mer. 8 août 2018 à 12:08, Louis Zipes  a
>> écrit :
>> 
>>> 
>>> Hi Calder, I can successfully start up as a Windows service and
>>> get JMX working BUT my problem is that Service doesn't stop
>>> cleanly (just repeating that problem in case it wasn't made
>>> clear).  It says the PORT is already in use which led me to try
>>> to use Catalina_Opts as per the suggestions on the internet.
>>> 
>>> Port already in use: 8008; nested exception is: 
>>> java.net.BindException: Address already in use: JVM_Bind
>>> 
>>> If you were able to get JMX working and you can start AND stop
>>> the Tomcat service cleanly, do you mind sharing me your
>>> 'scrubbed'  Java tab contents as I can seem to get the right
>>> combination to get it to Start and Stop the service.
>>> 
>>> Thanks, Louis
>>> 
>>> 
>>> 
>> Louis,
>> 
>> I believe you need to understand a bit more how things are
>> working with Java and the JVM. The -D options are pretty straight
>> forward for anyone knowing how you define properties to the JVM
>> on the command line. I already told you everything you need to
>> know to setup properly your Tomcat. Since you were the one
>> talking about CATALINA_OPTS I assumed you did know where and how
>> to setup the variable for your installation. Otherwise, just go
>> in the setup utility for Tomcat on Windows and put the 
>> -Dcom.sun.management.conf.file=${catalina.base}/conf/abc.def
>> entry there without the CATALINA_OPTS= stanza since this one's
>> intent is to set an environment variable for the process to pick
>> while the former is passing directly the property to the JVM from
>> the Tomcat Windows Setup dialog. There is many ways to do things.
>> Bottom line, you need to tell the JVM where is the configuration
>> file for JMX and put your properties in there as any other
>> properties file. This is standard stuff.
>> 
>> The effect is the JVM now knows your port is a JMX port and it
>> will stop to try to use it when it is already in use and free it
>> cleanly.
>> 
>> Regards,
>> 
>> - Daniel Savard
>> 
>> 
>>> 
>>> 
>> 
> 
> 
> -
>
> 
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 - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltsgHgACgkQHPApP6U8

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[tomcat]

Maybe it is time here to quote Arthur Clarke's 3rd law :
"Any sufficiently advanced technology is indistinguishable from magic"
(See : https://en.wikipedia.org/wiki/Clarke%27s_three_laws)

The process by which Tomcat is started and/or stopped - particularly under Windows and as 
a Service - is not very clear in the on-line documentation.
Neither is it it very easy to write a comprehensive and accurate documentation, because 
the thing has gotten to a point where, for mere mortals, it is really quite complicated.

(Have a look at bin/catalina.bat to get an idea).

So let me give you some overall pointers (some of them quite basic, I apologise), and 
maybe in there somewhere, you'll find wat you are missing to complete the picture and do 
what you want to do.


1) Tomcat is a compiled java application, in java bytecode.  To run this bytecode, you 
need a JVM. The JVM is machine-executable code, so to run tomcat, you run a JVM and tell 
it to run the tomcat bytecode.
2) the java JVM for Windows is not very good at running as a Windows Service (it does not 
handle the appropriate Windows "signals" etc.). To solve this, when you want to run tomcat 
as a Windows Service (or rather - see above - run the JVM as a Windows Service), you 
actually run a specialised "wrapper program" which does work well as a Windows Service, 
and you ask this wrapper to start the JVM which runs tomcat.
To make matters a bit more confusing (or maybe, for some, clearer), this generic "Windows 
Service JVM wrapper" is renamed to "tomcatV.exe" (where V is the tomcat version, so for 
tomcat 9, the program is called tomcat9.exe).
3) the wrapper program, when it starts the JVM, has to know which command-line switches it 
should pass to it.  For the Windows Service flavor of tomcat, these parameters are stored 
in a number of special keys in the Windows Registry, and that is where the wrapper picks 
them up, before starting the JVM.
4) To make it easier to set and edit these JVM command-line parameters, tomcat provides 
another Windows executable program - a specialised GUI Registry Editor - which is also 
renamed according to the tomcat version, as tomcatVw.exe (where V is the tomcat version, 
so for tomcat 9 it would be tomcat9w.exe).


5) as a separate bit of knowledge, I would suppose that everyone knows that on any given 
host, a given TCP listening port can only be opened by one process at a time. If a second 
process tries to open a port which is already opened by a first process, it will get an 
error of the kind "port already in use", and most probably the second process will then 
exit (non-gracefully).


6) in the tomcat conf/server.xml file, there is a tag :

This provides a clue as to how one actually *stops* tomcat : one opens a TCP connection to 
locahost port 8005 (on which tomcat listens), then sends the string "SHUTDOWN" on that 
connection. This causes tomcat to shutdown gracefully, at the end of which it does a 
"system.exit()" which shuts down the JVM that runs it.
And this in turn causes the JVM wrapper program to tell Windows that the tomcat Service is 
shutting down, before itself exiting. And thus is all well and tidy in the Windows Service 
world.


7) a helpful feature of tomcat, is that it itself provides code to connect to localhost 
port 8005 and send that shutdown string, so that one does not have to write its own 
separate program to do that.
The bit that is a bit confusing about this feature however, is that in order to use that 
code, one of course needs to start up another separate instance of tomcat, just to run 
that code and actually stop the "real" running tomcat.
And of course running a separate instance of tomcat actually means running a separate 
instance of the JVM which runs tomcat.


Now armed with all the above knowledge, and with the dialog window offered by the 
tomcat9w.exe program, it is relatively easy to figure out what happens (or at least what 
may happen in your case, in my modest non-java-expert opinion).


Looking only at the last 3 tabs of that window (Java / Startup / Shutdown), one can figure 
out that :
- the "java" tab contains the path of the JVM to be started, and the command-line 
parameters that will be passed to that JVM
- the "Startup" tab contains the java class that the JVM should invoke at the start of 
tomcat, and the argument ("start") to pass into that initial call.
- the "Shutdown" tab contains the java class that the JVM should invoke to stop an 
already-running tomcat, and the argument ("stop") to pass into that initial call.

(Thus triggering the code in (7) above).

And I believe that, in the particular case of Tomcat being run as a Windows Service, here 
may be the origin of the problem which you are encountering : the "Java" tab lists 
command-line options that are *common* to both the JVM which starts tomcat, and to the 
(separate) JVM which stops tomcat.  There is only one set of JVM options, for both cases.
Which means that if, in these JVM command-line 

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Mark Thomas]

On 09/08/18 12:11, Suvendu Sekhar Mondal wrote:
> On Thu, Aug 9, 2018 at 2:39 PM Mark Thomas  wrote:
>>
>> On 09/08/18 01:06, Daniel Savard wrote:
>>
>>> Louis,
>>>
>>> I believe you need to understand a bit more how things are working with
>>> Java and the JVM.
>>
>> Actually Daniel, it is you who needs to understand things better.
>>
>>
>> Louis,
>>
>> Clearly, when Tomcat is started a new JVM instance is created and it
>> listens on the configured JMX ports.
>>
>> The problem is that when Tomcat is stopped another JVM instance is
>> created (to send the stop message to the first) and that uses the same
>> configuration. Hence it tries to open the same JMX port and fails
>> because it is already bound.
>>
>> If you were running from the command line, the fix would be easy. Put
>> the JMX options in CATALINA_OPTS and they'd only be used on start but
>> not stop. (JAVA_OPTS are used on both start and stop).
>>
>> There is also a simple fix if running as a Windows Service. The Windows
>> Service wrapper is simply a renamed version Apache Common Daemon. When
>> running a Java program as a Windows service there are three ways it can
>> be integrated.
>>
>> 1. jvm. The Windows service wrapper starts and embedded JVM using the
>> provided parameters and then calls the start method on the appropriate
>> class. To stop, it calls the stop method on the appropriate class in the
>> embedded jvm.
>>
>> 2. Java. The Windows service wrapper starts a separate Java process with
>> the provided parameters. On stop, a second Java process is started using
>> the same parameters which is expected to communicate with the first
>> process and stop it.
>>
>> 3. exe. Same as 2 but any executable can be used rather than java.exe.
>>
>> You see the error you are see because you are using Java mode. Switch to
>> jvm mode and all should be well.
>>
>> Finally 7.0.54 is very old. I strongly recommend an upgrade at least to
>> the latest 7.0.x release is not 8.5.x/9.0.x
>>
>> Mark
>>
> One question Mark, if I use
> org.apache.catalina.mbeans.JmxRemoteLifecycleListener, would that work
> as JVM mode or Java mode?

That would work in either mode of the Windows Service wrapper.

If a second Java process is created to perform "stop", server.xml is
parsed but only to read the shutdown port and command. Everything else
is ignored.

Mark

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

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Mark Thomas]

On 09/08/18 12:45, Louis Zipes wrote:
> Hi Mark,
> 
> You wrote:
> 
> 1. You see the error you are see because you are using Java mode. Switch to 
> jvm mode and all should be well.
> 
>>> I'm already using 'C:\Program 
>>> Files\Java\jdk1.7.0_80\jre\bin\server\jvm.dll'  in my Java Virtual Machine 
>>> tab.  I assume that means I'm already in JVM Mode.  I think I recall when 
>>> setting up Tomcat last year it wouldn't start any other way.

It doesn't. The service wrapper can use that dll either to start Java in
process (jvm mode) or to start a separate process (Java mode).

You want to look at the bottom option on both the Startup and Shutdown
tabs of tomcat7w.exe. My expectation is that they will be set to "Java"
whereas you need "jvm".

Mark

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

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Hi Mark,

You wrote:

1. You see the error you are see because you are using Java mode. Switch to jvm 
mode and all should be well.

>> I'm already using 'C:\Program Files\Java\jdk1.7.0_80\jre\bin\server\jvm.dll' 
>>  in my Java Virtual Machine tab.  I assume that means I'm already in JVM 
>> Mode.  I think I recall when setting up Tomcat last year it wouldn't start 
>> any other way.

2. Finally 7.0.54 is very old. I strongly recommend an upgrade at least to the 
latest 7.0.x release is not 8.5.x/9.0.x

>> I'm going to try that today (or tomorrow depending on how busy it is at 
>> work).  The issue that I might run into is the application that is running 
>> on Tomcat is not my application and I might run into a restriction on how 
>> high of a version I can go to but I will deal with that later if it does 
>> work.

Thank you to all for the continued assistance.  I have a thick skin.   : )

- Louis

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, August 09, 2018 5:10 AM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


On 09/08/18 01:06, Daniel Savard wrote:

> Louis,
>
> I believe you need to understand a bit more how things are working with
> Java and the JVM.

Actually Daniel, it is you who needs to understand things better.


Louis,

Clearly, when Tomcat is started a new JVM instance is created and it
listens on the configured JMX ports.

The problem is that when Tomcat is stopped another JVM instance is
created (to send the stop message to the first) and that uses the same
configuration. Hence it tries to open the same JMX port and fails
because it is already bound.

If you were running from the command line, the fix would be easy. Put
the JMX options in CATALINA_OPTS and they'd only be used on start but
not stop. (JAVA_OPTS are used on both start and stop).

There is also a simple fix if running as a Windows Service. The Windows
Service wrapper is simply a renamed version Apache Common Daemon. When
running a Java program as a Windows service there are three ways it can
be integrated.

1. jvm. The Windows service wrapper starts and embedded JVM using the
provided parameters and then calls the start method on the appropriate
class. To stop, it calls the stop method on the appropriate class in the
embedded jvm.

2. Java. The Windows service wrapper starts a separate Java process with
the provided parameters. On stop, a second Java process is started using
the same parameters which is expected to communicate with the first
process and stop it.

3. exe. Same as 2 but any executable can be used rather than java.exe.

You see the error you are see because you are using Java mode. Switch to
jvm mode and all should be well.

Finally 7.0.54 is very old. I strongly recommend an upgrade at least to
the latest 7.0.x release is not 8.5.x/9.0.x

Mark

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

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

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

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Suvendu Sekhar Mondal]

On Thu, Aug 9, 2018 at 2:39 PM Mark Thomas  wrote:
>
> On 09/08/18 01:06, Daniel Savard wrote:
>
> > Louis,
> >
> > I believe you need to understand a bit more how things are working with
> > Java and the JVM.
>
> Actually Daniel, it is you who needs to understand things better.
>
>
> Louis,
>
> Clearly, when Tomcat is started a new JVM instance is created and it
> listens on the configured JMX ports.
>
> The problem is that when Tomcat is stopped another JVM instance is
> created (to send the stop message to the first) and that uses the same
> configuration. Hence it tries to open the same JMX port and fails
> because it is already bound.
>
> If you were running from the command line, the fix would be easy. Put
> the JMX options in CATALINA_OPTS and they'd only be used on start but
> not stop. (JAVA_OPTS are used on both start and stop).
>
> There is also a simple fix if running as a Windows Service. The Windows
> Service wrapper is simply a renamed version Apache Common Daemon. When
> running a Java program as a Windows service there are three ways it can
> be integrated.
>
> 1. jvm. The Windows service wrapper starts and embedded JVM using the
> provided parameters and then calls the start method on the appropriate
> class. To stop, it calls the stop method on the appropriate class in the
> embedded jvm.
>
> 2. Java. The Windows service wrapper starts a separate Java process with
> the provided parameters. On stop, a second Java process is started using
> the same parameters which is expected to communicate with the first
> process and stop it.
>
> 3. exe. Same as 2 but any executable can be used rather than java.exe.
>
> You see the error you are see because you are using Java mode. Switch to
> jvm mode and all should be well.
>
> Finally 7.0.54 is very old. I strongly recommend an upgrade at least to
> the latest 7.0.x release is not 8.5.x/9.0.x
>
> Mark
>
One question Mark, if I use
org.apache.catalina.mbeans.JmxRemoteLifecycleListener, would that work
as JVM mode or Java mode?

Thanks!
Suvendu

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

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Mark Thomas]

On 09/08/18 01:06, Daniel Savard wrote:

> Louis,
> 
> I believe you need to understand a bit more how things are working with
> Java and the JVM.

Actually Daniel, it is you who needs to understand things better.


Louis,

Clearly, when Tomcat is started a new JVM instance is created and it
listens on the configured JMX ports.

The problem is that when Tomcat is stopped another JVM instance is
created (to send the stop message to the first) and that uses the same
configuration. Hence it tries to open the same JMX port and fails
because it is already bound.

If you were running from the command line, the fix would be easy. Put
the JMX options in CATALINA_OPTS and they'd only be used on start but
not stop. (JAVA_OPTS are used on both start and stop).

There is also a simple fix if running as a Windows Service. The Windows
Service wrapper is simply a renamed version Apache Common Daemon. When
running a Java program as a Windows service there are three ways it can
be integrated.

1. jvm. The Windows service wrapper starts and embedded JVM using the
provided parameters and then calls the start method on the appropriate
class. To stop, it calls the stop method on the appropriate class in the
embedded jvm.

2. Java. The Windows service wrapper starts a separate Java process with
the provided parameters. On stop, a second Java process is started using
the same parameters which is expected to communicate with the first
process and stop it.

3. exe. Same as 2 but any executable can be used rather than java.exe.

You see the error you are see because you are using Java mode. Switch to
jvm mode and all should be well.

Finally 7.0.54 is very old. I strongly recommend an upgrade at least to
the latest 7.0.x release is not 8.5.x/9.0.x

Mark

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

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Daniel Savard]

Le mer. 8 août 2018 à 12:08, Louis Zipes  a écrit :

>
> Hi Calder,
> I can successfully start up as a Windows service and get JMX working BUT
> my problem is that Service doesn't stop cleanly (just repeating that
> problem in case it wasn't made clear).  It says the PORT is already in use
> which led me to try to use Catalina_Opts as per the suggestions on the
> internet.
>
> Port already in use: 8008; nested exception is:
>java.net.BindException: Address already in use: JVM_Bind
>
> If you were able to get JMX working and you can start AND stop the Tomcat
> service cleanly, do you mind sharing me your 'scrubbed'  Java tab contents
> as I can seem to get the right combination to get it to Start and Stop the
> service.
>
> Thanks, Louis
>
>
>
Louis,

I believe you need to understand a bit more how things are working with
Java and the JVM. The -D options are pretty straight forward for anyone
knowing how you define properties to the JVM on the command line. I already
told you everything you need to know to setup properly your Tomcat. Since
you were the one talking about CATALINA_OPTS I assumed you did know where
and how to setup the variable for your installation. Otherwise, just go in
the setup utility for Tomcat on Windows and put the
-Dcom.sun.management.conf.file=${catalina.base}/conf/abc.def entry there
without the CATALINA_OPTS= stanza since this one's intent is to set an
environment variable for the process to pick while the former is passing
directly the property to the JVM from the Tomcat Windows Setup dialog.
There is many ways to do things. Bottom line, you need to tell the JVM
where is the configuration file for JMX and put your properties in there as
any other properties file. This is standard stuff.

The effect is the JVM now knows your port is a JMX port and it will stop to
try to use it when it is already in use and free it cleanly.

Regards,

-
Daniel Savard


>
>

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Hi Calder,
I can successfully start up as a Windows service and get JMX working BUT my 
problem is that Service doesn't stop cleanly (just repeating that problem in 
case it wasn't made clear).  It says the PORT is already in use which led me to 
try to use Catalina_Opts as per the suggestions on the internet.

Port already in use: 8008; nested exception is:
   java.net.BindException: Address already in use: JVM_Bind

If you were able to get JMX working and you can start AND stop the Tomcat 
service cleanly, do you mind sharing me your 'scrubbed'  Java tab contents as I 
can seem to get the right combination to get it to Start and Stop the service.

Thanks, Louis

-Original Message-
From: calder [mailto:calder@gmail.com]
Sent: Wednesday, August 08, 2018 12:01 PM
To: Tomcat Users List
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


I configured my "Tomcat as a Service" a couple days ago for remote JMC

a) navigate to Tomcat's "bin" subdir
b) execute: tomcat7w  //ES//"type service name here"
c) go to Java tab
d) add the properties in the "Java Options" text area
e) select OK and restart Tomcat Service


On Wednesday, August 8, 2018, Louis Zipes  wrote:

> Thanks for the assistance!  See my comments below:
>
> >You put this to setenv.bat in your bin directory. If the setenv.bat file
> does not exist, create it
>
> -- My problem throughout this is that I'm starting up my Tomcat using
> Windows service so setenv.bat and catalina.bat seems to be ignored in that
> scenario.   Correct me if I'm wrong but everything on Google mentions this.
>
> >Note that you can also set your properties in CATALINA_OPTS directly,
> i.e. you'd delete the line above in setenv.bat and paste in:
>
> -- When you say 'Set Catalina_Opts directly' do you mean the Environment
> variable  or some other location?
>
> -Original Message-
> From: Marek Czernek [mailto:mczer...@redhat.com]
> Sent: Wednesday, August 08, 2018 9:39 AM
> To: users@tomcat.apache.org
> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> Hi Louis,
>
> try the following format:
>
> set
> CATALINA_OPTS="-Dcom.sun.management.conf.file=%
> CATALINA_BASE%\conf\abc.efg"
>
> In the above, %CATALINA_BASE% is a bariable that should be resolved by
> Tomcat. If it is not, I made a mistake in the variable name, but I think
> it should work (you could also try %catalina.base%).
>
> You put this to setenv.bat in your bin directory. If the setenv.bat file
> does not exist, create it. Note that you can also set your properties in
> CATALINA_OPTS directly, i.e. you'd delete the line above in setenv.bat
> and paste in:
>
> set CATALINA_OPTS="-Dproperty1=value1 -Dproperty2=value2" etc. When you
> start Tomcat, it should read all the properties in CATALINA_OPTS and
> show you the properties at the beginning of the log.
>
> Hope this helps.
>
> On 08/08/2018 03:10 PM, Louis Zipes wrote:
> > Hi Daniel,
> > I apologize if maybe it is my lack of knowledge but I don't think I
> understand the actual way to write the line 'Set Catalina_Opts ='  in this
> management file that I'm going to reference in the Java window/tabe in the
> Tomcat 7w GUI.
> >
> > In my management.properties file (in the /CONF folder which is where
> also the server.xml file sits) I have the following
> >
> > com.sun.management.jmxremote
> > com.sun.management.jmxremote.port=8008
> > com.sun.management.jmxremote.authenticate=false
> > com.sun.management.jmxremote.ssl=false
> > java.rmi.server.hostname=
> >
> > How do I set these as my CATALINA_OPTS values?  I have tried various
> 'SET CATALINA_OPTS...' options but I can't seem to write it the correct way
> for Windows.  I have even tried to set the CATALINA_OPTS option, pointing
> to the management.properties file in the Java tab in the Tomcat7w GUI but I
> get an error that the Class can't be found so I must be writing it wrong.
> >
> > Thanks for the continued assistance.
> >
> > - Louis
> >
> >
> >
> > -Original Message-
> > From: Daniel Savard [mailto:daniel.sav...@gmail.com]
> > Sent: Friday, August 03, 2018 11:57 PM
> > To: Tomcat Users List
> > Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
> >
> > - - - external message, proceed with caution - - -
> >
> >
> > Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit
> :

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[calder]

I configured my "Tomcat as a Service" a couple days ago for remote JMC

a) navigate to Tomcat's "bin" subdir
b) execute: tomcat7w  //ES//"type service name here"
c) go to Java tab
d) add the properties in the "Java Options" text area
e) select OK and restart Tomcat Service


On Wednesday, August 8, 2018, Louis Zipes  wrote:

> Thanks for the assistance!  See my comments below:
>
> >You put this to setenv.bat in your bin directory. If the setenv.bat file
> does not exist, create it
>
> -- My problem throughout this is that I'm starting up my Tomcat using
> Windows service so setenv.bat and catalina.bat seems to be ignored in that
> scenario.   Correct me if I'm wrong but everything on Google mentions this.
>
> >Note that you can also set your properties in CATALINA_OPTS directly,
> i.e. you'd delete the line above in setenv.bat and paste in:
>
> -- When you say 'Set Catalina_Opts directly' do you mean the Environment
> variable  or some other location?
>
> -Original Message-
> From: Marek Czernek [mailto:mczer...@redhat.com]
> Sent: Wednesday, August 08, 2018 9:39 AM
> To: users@tomcat.apache.org
> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> Hi Louis,
>
> try the following format:
>
> set
> CATALINA_OPTS="-Dcom.sun.management.conf.file=%
> CATALINA_BASE%\conf\abc.efg"
>
> In the above, %CATALINA_BASE% is a bariable that should be resolved by
> Tomcat. If it is not, I made a mistake in the variable name, but I think
> it should work (you could also try %catalina.base%).
>
> You put this to setenv.bat in your bin directory. If the setenv.bat file
> does not exist, create it. Note that you can also set your properties in
> CATALINA_OPTS directly, i.e. you'd delete the line above in setenv.bat
> and paste in:
>
> set CATALINA_OPTS="-Dproperty1=value1 -Dproperty2=value2" etc. When you
> start Tomcat, it should read all the properties in CATALINA_OPTS and
> show you the properties at the beginning of the log.
>
> Hope this helps.
>
> On 08/08/2018 03:10 PM, Louis Zipes wrote:
> > Hi Daniel,
> > I apologize if maybe it is my lack of knowledge but I don't think I
> understand the actual way to write the line 'Set Catalina_Opts ='  in this
> management file that I'm going to reference in the Java window/tabe in the
> Tomcat 7w GUI.
> >
> > In my management.properties file (in the /CONF folder which is where
> also the server.xml file sits) I have the following
> >
> > com.sun.management.jmxremote
> > com.sun.management.jmxremote.port=8008
> > com.sun.management.jmxremote.authenticate=false
> > com.sun.management.jmxremote.ssl=false
> > java.rmi.server.hostname=
> >
> > How do I set these as my CATALINA_OPTS values?  I have tried various
> 'SET CATALINA_OPTS...' options but I can't seem to write it the correct way
> for Windows.  I have even tried to set the CATALINA_OPTS option, pointing
> to the management.properties file in the Java tab in the Tomcat7w GUI but I
> get an error that the Class can't be found so I must be writing it wrong.
> >
> > Thanks for the continued assistance.
> >
> > - Louis
> >
> >
> >
> > -Original Message-
> > From: Daniel Savard [mailto:daniel.sav...@gmail.com]
> > Sent: Friday, August 03, 2018 11:57 PM
> > To: Tomcat Users List
> > Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
> >
> > - - - external message, proceed with caution - - -
> >
> >
> > Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit
> :
> >
> >> Good catch!!  I still had 'd' in front of my lines so once I removed
> those
> >> JMX starts up using Management.properties file but as you mentioned it
> >> doesn't really change the behavior at all and the Service still doesn't
> >> stop cleanly.  So is there a way to force the JMX to use CATALINA_OPTS
> in
> >> this file.  Something like SET CATALINA_OPTS = 'JMX settings'?
> >>
> >> That is if the JMX running on CATALINA_OPTS is indeed the answer.
> >> Basically, trying to mimic the setenv file that is not used by the
> Window
> >> Service.
> >>
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Friday, August 03, 2018 11:52 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> >>

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Thanks for the assistance!  See my comments below:

>You put this to setenv.bat in your bin directory. If the setenv.bat file does 
>not exist, create it

-- My problem throughout this is that I'm starting up my Tomcat using Windows 
service so setenv.bat and catalina.bat seems to be ignored in that scenario.   
Correct me if I'm wrong but everything on Google mentions this.

>Note that you can also set your properties in CATALINA_OPTS directly, i.e. 
>you'd delete the line above in setenv.bat and paste in:

-- When you say 'Set Catalina_Opts directly' do you mean the Environment 
variable  or some other location?

-Original Message-
From: Marek Czernek [mailto:mczer...@redhat.com]
Sent: Wednesday, August 08, 2018 9:39 AM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


Hi Louis,

try the following format:

set
CATALINA_OPTS="-Dcom.sun.management.conf.file=%CATALINA_BASE%\conf\abc.efg"

In the above, %CATALINA_BASE% is a bariable that should be resolved by
Tomcat. If it is not, I made a mistake in the variable name, but I think
it should work (you could also try %catalina.base%).

You put this to setenv.bat in your bin directory. If the setenv.bat file
does not exist, create it. Note that you can also set your properties in
CATALINA_OPTS directly, i.e. you'd delete the line above in setenv.bat
and paste in:

set CATALINA_OPTS="-Dproperty1=value1 -Dproperty2=value2" etc. When you
start Tomcat, it should read all the properties in CATALINA_OPTS and
show you the properties at the beginning of the log.

Hope this helps.

On 08/08/2018 03:10 PM, Louis Zipes wrote:
> Hi Daniel,
> I apologize if maybe it is my lack of knowledge but I don't think I 
> understand the actual way to write the line 'Set Catalina_Opts ='  in this 
> management file that I'm going to reference in the Java window/tabe in the 
> Tomcat 7w GUI.
>
> In my management.properties file (in the /CONF folder which is where also the 
> server.xml file sits) I have the following
>
> com.sun.management.jmxremote
> com.sun.management.jmxremote.port=8008
> com.sun.management.jmxremote.authenticate=false
> com.sun.management.jmxremote.ssl=false
> java.rmi.server.hostname=
>
> How do I set these as my CATALINA_OPTS values?  I have tried various 'SET 
> CATALINA_OPTS...' options but I can't seem to write it the correct way for 
> Windows.  I have even tried to set the CATALINA_OPTS option, pointing to the 
> management.properties file in the Java tab in the Tomcat7w GUI but I get an 
> error that the Class can't be found so I must be writing it wrong.
>
> Thanks for the continued assistance.
>
> - Louis
>
>
>
> -Original Message-
> From: Daniel Savard [mailto:daniel.sav...@gmail.com]
> Sent: Friday, August 03, 2018 11:57 PM
> To: Tomcat Users List
> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using 
> a Windows Service in Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit :
>
>> Good catch!!  I still had 'd' in front of my lines so once I removed those
>> JMX starts up using Management.properties file but as you mentioned it
>> doesn't really change the behavior at all and the Service still doesn't
>> stop cleanly.  So is there a way to force the JMX to use CATALINA_OPTS in
>> this file.  Something like SET CATALINA_OPTS = 'JMX settings'?
>>
>> That is if the JMX running on CATALINA_OPTS is indeed the answer.
>> Basically, trying to mimic the setenv file that is not used by the Window
>> Service.
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Friday, August 03, 2018 11:52 AM
>> To: users@tomcat.apache.org
>> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
>> using a Windows Service in Tomcat 7.0.54
>>
>> - - - external message, proceed with caution - - -
>>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Louis,
>>
>> On 8/3/18 11:32 AM, Louis Zipes wrote:
>>> Hi Daniel, I tried your suggestion and while I think it is now
>>> acknowledging the existence of the management.properties file
>>> (Windows Service wouldn't start if I purposely misspelled
>>> 'managemenX.properties') but it doesn't seem to be actually working
>>> (JMX can't connect).
>>>
>>> What I did:
>>>
>>> I created a copy of an existing logging.properties file already in
>>> the CONF folder, renamed it management.properties, and removed all
>

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Marek Czernek]

Hi Louis,

try the following format:

set 
CATALINA_OPTS="-Dcom.sun.management.conf.file=%CATALINA_BASE%\conf\abc.efg"


In the above, %CATALINA_BASE% is a bariable that should be resolved by 
Tomcat. If it is not, I made a mistake in the variable name, but I think 
it should work (you could also try %catalina.base%).


You put this to setenv.bat in your bin directory. If the setenv.bat file 
does not exist, create it. Note that you can also set your properties in 
CATALINA_OPTS directly, i.e. you'd delete the line above in setenv.bat 
and paste in:


set CATALINA_OPTS="-Dproperty1=value1 -Dproperty2=value2" etc. When you 
start Tomcat, it should read all the properties in CATALINA_OPTS and 
show you the properties at the beginning of the log.


Hope this helps.

On 08/08/2018 03:10 PM, Louis Zipes wrote:

Hi Daniel,
I apologize if maybe it is my lack of knowledge but I don't think I understand 
the actual way to write the line 'Set Catalina_Opts ='  in this management file 
that I'm going to reference in the Java window/tabe in the Tomcat 7w GUI.

In my management.properties file (in the /CONF folder which is where also the 
server.xml file sits) I have the following

com.sun.management.jmxremote
com.sun.management.jmxremote.port=8008
com.sun.management.jmxremote.authenticate=false
com.sun.management.jmxremote.ssl=false
java.rmi.server.hostname=

How do I set these as my CATALINA_OPTS values?  I have tried various 'SET 
CATALINA_OPTS...' options but I can't seem to write it the correct way for 
Windows.  I have even tried to set the CATALINA_OPTS option, pointing to the 
management.properties file in the Java tab in the Tomcat7w GUI but I get an 
error that the Class can't be found so I must be writing it wrong.

Thanks for the continued assistance.

- Louis



-Original Message-
From: Daniel Savard [mailto:daniel.sav...@gmail.com]
Sent: Friday, August 03, 2018 11:57 PM
To: Tomcat Users List
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit :


Good catch!!  I still had 'd' in front of my lines so once I removed those
JMX starts up using Management.properties file but as you mentioned it
doesn't really change the behavior at all and the Service still doesn't
stop cleanly.  So is there a way to force the JMX to use CATALINA_OPTS in
this file.  Something like SET CATALINA_OPTS = 'JMX settings'?

That is if the JMX running on CATALINA_OPTS is indeed the answer.
Basically, trying to mimic the setenv file that is not used by the Window
Service.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, August 03, 2018 11:52 AM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
using a Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/3/18 11:32 AM, Louis Zipes wrote:

Hi Daniel, I tried your suggestion and while I think it is now
acknowledging the existence of the management.properties file
(Windows Service wouldn't start if I purposely misspelled
'managemenX.properties') but it doesn't seem to be actually working
(JMX can't connect).

What I did:

I created a copy of an existing logging.properties file already in
the CONF folder, renamed it management.properties, and removed all
contents of it and put in:

Just FYI, there is nothing magical about an existing properties file.
It's just a text file with name=value items in it.


Dcom.sun.management.jmxremote
Dcom.sun.management.jmxremote.port=8008
Dcom.sun.management.jmxremote.authenticate=false
Dcom.sun.management.jmxremote.ssl=false
Djava.rmi.server.hostname=

I don't think you want those leading D characters. Is that a
copy/paste error?


-Dcom.sun.management.config.file= C:\ \Tomcat\conf\management.properties

Daniel usually knows what he's talking about, but I'll be surprised if
Tomcat doesn't fail the same way after making these changes... you are
just moving the configuration from one place (multiple system
properties) to another (one system property pointing to another file
of properties).

- -chris


As Christopher said, you this file management.properties can be named
whatever abc.efg would do the same and in that file you have
attribute=value pairs, everything that concerns the com.sun.management.xxx
properties. Then you pass the name of that file as a single option to the
JVM with -Dcom.sun.management.config.file=${catalina.base}/conf/abc.efg and
remove everything else from the CATALINA_OPTS which is in the configuration
file. I strongly suggest to locate this file in the same directory as the
server.xml file and use the ${catalina.base} variable asis and litterally
into the 
CATALINA_OPTS="-Dcom.sun.management.conf.file=${catalina.base}/conf/abc.efg"

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Hi Daniel,
I apologize if maybe it is my lack of knowledge but I don't think I understand 
the actual way to write the line 'Set Catalina_Opts ='  in this management file 
that I'm going to reference in the Java window/tabe in the Tomcat 7w GUI.

In my management.properties file (in the /CONF folder which is where also the 
server.xml file sits) I have the following

com.sun.management.jmxremote
com.sun.management.jmxremote.port=8008
com.sun.management.jmxremote.authenticate=false
com.sun.management.jmxremote.ssl=false
java.rmi.server.hostname=

How do I set these as my CATALINA_OPTS values?  I have tried various 'SET 
CATALINA_OPTS...' options but I can't seem to write it the correct way for 
Windows.  I have even tried to set the CATALINA_OPTS option, pointing to the 
management.properties file in the Java tab in the Tomcat7w GUI but I get an 
error that the Class can't be found so I must be writing it wrong.

Thanks for the continued assistance.

- Louis



-Original Message-
From: Daniel Savard [mailto:daniel.sav...@gmail.com]
Sent: Friday, August 03, 2018 11:57 PM
To: Tomcat Users List
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit :

> Good catch!!  I still had 'd' in front of my lines so once I removed those
> JMX starts up using Management.properties file but as you mentioned it
> doesn't really change the behavior at all and the Service still doesn't
> stop cleanly.  So is there a way to force the JMX to use CATALINA_OPTS in
> this file.  Something like SET CATALINA_OPTS = 'JMX settings'?
>
> That is if the JMX running on CATALINA_OPTS is indeed the answer.
> Basically, trying to mimic the setenv file that is not used by the Window
> Service.
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, August 03, 2018 11:52 AM
> To: users@tomcat.apache.org
> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Louis,
>
> On 8/3/18 11:32 AM, Louis Zipes wrote:
> > Hi Daniel, I tried your suggestion and while I think it is now
> > acknowledging the existence of the management.properties file
> > (Windows Service wouldn't start if I purposely misspelled
> > 'managemenX.properties') but it doesn't seem to be actually working
> > (JMX can't connect).
> >
> > What I did:
> >
> > I created a copy of an existing logging.properties file already in
> > the CONF folder, renamed it management.properties, and removed all
> > contents of it and put in:
>
> Just FYI, there is nothing magical about an existing properties file.
> It's just a text file with name=value items in it.
>
> > Dcom.sun.management.jmxremote
> > Dcom.sun.management.jmxremote.port=8008
> > Dcom.sun.management.jmxremote.authenticate=false
> > Dcom.sun.management.jmxremote.ssl=false
> > Djava.rmi.server.hostname=
>
> I don't think you want those leading D characters. Is that a
> copy/paste error?
>
> > -Dcom.sun.management.config.file= C:\  > structure>\Tomcat\conf\management.properties
>
> Daniel usually knows what he's talking about, but I'll be surprised if
> Tomcat doesn't fail the same way after making these changes... you are
> just moving the configuration from one place (multiple system
> properties) to another (one system property pointing to another file
> of properties).
>
> - -chris
>

As Christopher said, you this file management.properties can be named
whatever abc.efg would do the same and in that file you have
attribute=value pairs, everything that concerns the com.sun.management.xxx
properties. Then you pass the name of that file as a single option to the
JVM with -Dcom.sun.management.config.file=${catalina.base}/conf/abc.efg and
remove everything else from the CATALINA_OPTS which is in the configuration
file. I strongly suggest to locate this file in the same directory as the
server.xml file and use the ${catalina.base} variable asis and litterally
into the 
CATALINA_OPTS="-Dcom.sun.management.conf.file=${catalina.base}/conf/abc.efg"
definition.

I skipped other configuration files for authentication, in my case I am
authenticating the users against the Active Directory database. So, the
informations I gave for the content of the configuration file is incomplete
and do not necessarily apply to your case, that's why I didn't bother to
put it in my original post. But, you may have to use extra properties for
you particular situation.

Why did I say to put everything in the configur

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Daniel Savard]

Le ven. 3 août 2018 à 12:03, Louis Zipes  a écrit :

> Good catch!!  I still had 'd' in front of my lines so once I removed those
> JMX starts up using Management.properties file but as you mentioned it
> doesn't really change the behavior at all and the Service still doesn't
> stop cleanly.  So is there a way to force the JMX to use CATALINA_OPTS in
> this file.  Something like SET CATALINA_OPTS = 'JMX settings'?
>
> That is if the JMX running on CATALINA_OPTS is indeed the answer.
> Basically, trying to mimic the setenv file that is not used by the Window
> Service.
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, August 03, 2018 11:52 AM
> To: users@tomcat.apache.org
> Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat
> using a Windows Service in Tomcat 7.0.54
>
> - - - external message, proceed with caution - - -
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Louis,
>
> On 8/3/18 11:32 AM, Louis Zipes wrote:
> > Hi Daniel, I tried your suggestion and while I think it is now
> > acknowledging the existence of the management.properties file
> > (Windows Service wouldn't start if I purposely misspelled
> > 'managemenX.properties') but it doesn't seem to be actually working
> > (JMX can't connect).
> >
> > What I did:
> >
> > I created a copy of an existing logging.properties file already in
> > the CONF folder, renamed it management.properties, and removed all
> > contents of it and put in:
>
> Just FYI, there is nothing magical about an existing properties file.
> It's just a text file with name=value items in it.
>
> > Dcom.sun.management.jmxremote
> > Dcom.sun.management.jmxremote.port=8008
> > Dcom.sun.management.jmxremote.authenticate=false
> > Dcom.sun.management.jmxremote.ssl=false
> > Djava.rmi.server.hostname=
>
> I don't think you want those leading D characters. Is that a
> copy/paste error?
>
> > -Dcom.sun.management.config.file= C:\  > structure>\Tomcat\conf\management.properties
>
> Daniel usually knows what he's talking about, but I'll be surprised if
> Tomcat doesn't fail the same way after making these changes... you are
> just moving the configuration from one place (multiple system
> properties) to another (one system property pointing to another file
> of properties).
>
> - -chris
>

As Christopher said, you this file management.properties can be named
whatever abc.efg would do the same and in that file you have
attribute=value pairs, everything that concerns the com.sun.management.xxx
properties. Then you pass the name of that file as a single option to the
JVM with -Dcom.sun.management.config.file=${catalina.base}/conf/abc.efg and
remove everything else from the CATALINA_OPTS which is in the configuration
file. I strongly suggest to locate this file in the same directory as the
server.xml file and use the ${catalina.base} variable asis and litterally
into the 
CATALINA_OPTS="-Dcom.sun.management.conf.file=${catalina.base}/conf/abc.efg"
definition.

I skipped other configuration files for authentication, in my case I am
authenticating the users against the Active Directory database. So, the
informations I gave for the content of the configuration file is incomplete
and do not necessarily apply to your case, that's why I didn't bother to
put it in my original post. But, you may have to use extra properties for
you particular situation.

Why did I say to put everything in the configuration file for
com.sun.management.config.file? Because that way, the JVM knows these are
for JMX and knows the port is for JMX and will not run into a nonesense
when stopping the service saying the port is already in use. That's why you
should put this into the configuration file and define the property to tell
the JVM the pathname of the configuration file.

Regards,
-
Daniel Savard

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Good catch!!  I still had 'd' in front of my lines so once I removed those JMX 
starts up using Management.properties file but as you mentioned it doesn't 
really change the behavior at all and the Service still doesn't stop cleanly.  
So is there a way to force the JMX to use CATALINA_OPTS in this file.  
Something like SET CATALINA_OPTS = 'JMX settings'?

That is if the JMX running on CATALINA_OPTS is indeed the answer.  Basically, 
trying to mimic the setenv file that is not used by the Window Service.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, August 03, 2018 11:52 AM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/3/18 11:32 AM, Louis Zipes wrote:
> Hi Daniel, I tried your suggestion and while I think it is now
> acknowledging the existence of the management.properties file
> (Windows Service wouldn't start if I purposely misspelled
> 'managemenX.properties') but it doesn't seem to be actually working
> (JMX can't connect).
>
> What I did:
>
> I created a copy of an existing logging.properties file already in
> the CONF folder, renamed it management.properties, and removed all
> contents of it and put in:

Just FYI, there is nothing magical about an existing properties file.
It's just a text file with name=value items in it.

> Dcom.sun.management.jmxremote
> Dcom.sun.management.jmxremote.port=8008
> Dcom.sun.management.jmxremote.authenticate=false
> Dcom.sun.management.jmxremote.ssl=false
> Djava.rmi.server.hostname=

I don't think you want those leading D characters. Is that a
copy/paste error?

> -Dcom.sun.management.config.file= C:\  structure>\Tomcat\conf\management.properties

Daniel usually knows what he's talking about, but I'll be surprised if
Tomcat doesn't fail the same way after making these changes... you are
just moving the configuration from one place (multiple system
properties) to another (one system property pointing to another file
of properties).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltkejcACgkQHPApP6U8
pFjRPBAAghgmIUA3IBV7qWtk2icUSTOkmF1qd7oFt64pwkitSQmlmJ0FecnDJwVH
OoMCEB9yg1KvtIKMOJ9nHDIgTn7an0iS7wK2MzbKZs4cWMAqpxagS6S2M1AmygNr
pnsig+WTSmO2r5OkcdWM+JE2qmn+oeQecf2E439RIkEcb/OuzTIJLjk0iIVKSOlQ
EihDsVKh+dBvDyDol5RC9k+cxNxNQyYH06ZcOKOTbJCOclMvSUqcqpLesEWnoM5r
Zh1TaOXc40HtcvtBQCda6aOdrQE/qieI4pxtduT0BDGxBnjS2GijitrY1isqVv0k
RnUYGbvGlcI3OHdfUBAkitl0Bhrx24zqDnaFJ73PHuItlP0aqBeH7eSMTwt5AGXg
T7h3PylWdpeL8G2qh1MEdvUCzRKStOHqAYweKnwb0REuNf4YJs6t8n+zRc1sbnkk
bNXidsZlUD5ofxdh9fSVeWKiPnHfEYNz3aDqlavymgN1mKDkNJ+qmZoxctEUdKSo
Gv4/vNhNOHK6Vb7RSYyp2Ac87jxy4DDl+RL5ltv2oDAp1rIoH1EamDzOTMiJtFpk
Sy6EyW8PqWjoLzOBsBC8gH8OdJUNojRkTrl/D+B/dysAEz1tsUw5Kj/4o0HRPvIU
svv56gDNaOPTfMbXQvX4vyykfCAxYKKBouB0zyjp7GAY0+4SAG4=
=LV/k
-END PGP SIGNATURE-

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

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/3/18 11:32 AM, Louis Zipes wrote:
> Hi Daniel, I tried your suggestion and while I think it is now
> acknowledging the existence of the management.properties file
> (Windows Service wouldn't start if I purposely misspelled
> 'managemenX.properties') but it doesn't seem to be actually working
> (JMX can't connect).
> 
> What I did:
> 
> I created a copy of an existing logging.properties file already in
> the CONF folder, renamed it management.properties, and removed all
> contents of it and put in:

Just FYI, there is nothing magical about an existing properties file.
It's just a text file with name=value items in it.

> Dcom.sun.management.jmxremote 
> Dcom.sun.management.jmxremote.port=8008 
> Dcom.sun.management.jmxremote.authenticate=false 
> Dcom.sun.management.jmxremote.ssl=false 
> Djava.rmi.server.hostname=

I don't think you want those leading D characters. Is that a
copy/paste error?

> -Dcom.sun.management.config.file= C:\  structure>\Tomcat\conf\management.properties

Daniel usually knows what he's talking about, but I'll be surprised if
Tomcat doesn't fail the same way after making these changes... you are
just moving the configuration from one place (multiple system
properties) to another (one system property pointing to another file
of properties).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltkejcACgkQHPApP6U8
pFjRPBAAghgmIUA3IBV7qWtk2icUSTOkmF1qd7oFt64pwkitSQmlmJ0FecnDJwVH
OoMCEB9yg1KvtIKMOJ9nHDIgTn7an0iS7wK2MzbKZs4cWMAqpxagS6S2M1AmygNr
pnsig+WTSmO2r5OkcdWM+JE2qmn+oeQecf2E439RIkEcb/OuzTIJLjk0iIVKSOlQ
EihDsVKh+dBvDyDol5RC9k+cxNxNQyYH06ZcOKOTbJCOclMvSUqcqpLesEWnoM5r
Zh1TaOXc40HtcvtBQCda6aOdrQE/qieI4pxtduT0BDGxBnjS2GijitrY1isqVv0k
RnUYGbvGlcI3OHdfUBAkitl0Bhrx24zqDnaFJ73PHuItlP0aqBeH7eSMTwt5AGXg
T7h3PylWdpeL8G2qh1MEdvUCzRKStOHqAYweKnwb0REuNf4YJs6t8n+zRc1sbnkk
bNXidsZlUD5ofxdh9fSVeWKiPnHfEYNz3aDqlavymgN1mKDkNJ+qmZoxctEUdKSo
Gv4/vNhNOHK6Vb7RSYyp2Ac87jxy4DDl+RL5ltv2oDAp1rIoH1EamDzOTMiJtFpk
Sy6EyW8PqWjoLzOBsBC8gH8OdJUNojRkTrl/D+B/dysAEz1tsUw5Kj/4o0HRPvIU
svv56gDNaOPTfMbXQvX4vyykfCAxYKKBouB0zyjp7GAY0+4SAG4=
=LV/k
-END PGP SIGNATURE-

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

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Hi Daniel,
I tried your suggestion and while I think it is now acknowledging the existence 
of the management.properties file (Windows Service wouldn't start if I 
purposely misspelled 'managemenX.properties') but it doesn't seem to be 
actually working  (JMX can't connect).

What I did:

I created a copy of an existing logging.properties file already in the CONF 
folder, renamed it management.properties, and removed all contents of it and 
put in:

Dcom.sun.management.jmxremote
Dcom.sun.management.jmxremote.port=8008
Dcom.sun.management.jmxremote.authenticate=false
Dcom.sun.management.jmxremote.ssl=false
Djava.rmi.server.hostname=

And then in the Tomcat7w GUI under the Java tab I added it (last line)

-Dcatalina.home=C:\ \Tomcat
-Dcatalina.base=C:\ \Tomcat
-Djava.endorsed.dirs=C:\ \Tomcat\endorsed
-Djava.io.tmpdir=C:\ \Tomcat\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=C:\ \Tomcat\conf\logging.properties
-Dcom.sun.management.config.file= C:\ \Tomcat\conf\management.properties<== new line

But it didn't connect through when opening  up jconsole.exe under C:\Program 
Files\Java\jdk1.7.0_80\bin and I didn't see the PORT being used when I did 
NETSTAT.  Note that I did an ECHO %CATALINA_OPTS% to make sure it wasn't hiding 
somewhere and nothing was returned

Finally, just to confirm that my parameters in the management.properties file 
were correct I add in the contents of it back into the Tomcat7w GUI under the 
Java tab like I had originally set up (JMX does now work BUT my original 
problem of not being able to stop the Service cleanly returns)

-Dcatalina.home=C:\ \Tomcat
-Dcatalina.base=C:\ \Tomcat
-Djava.endorsed.dirs=C:\ \Tomcat\endorsed
-Djava.io.tmpdir=C:\ \Tomcat\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=C:\ \Tomcat\conf\logging.properties
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8008
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=

Did I miss something in your instructions?

Thanks, Louis

-Original Message-
From: Daniel Savard [mailto:daniel.sav...@gmail.com]
Sent: Thursday, August 02, 2018 6:15 PM
To: Tomcat Users List
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


In ${Tomcat}/conf create the file management.properties and put your stuff
in this file like:

com.sun.management.jmxremote = true
com.sun.management.jmxremote.port = 9876
com.sun.management.registry.ssl =true
com.sun.management.ssl = true
com.sun.management.ssl.enebled.protocols = TLSv1.2
...

Then, remove your stuff from the CATALINA_OPTS and just point to this file
with
-Dcom.sun.management.config.file=${CATALINA_BASE}/conf/management.properties
and you port in use message will disappear since this configuration will be
handled properly.

Regards,

Le 2 août 2018 3:58 PM, "Louis Zipes"  a écrit :

Hi All,
I'm trying to enable JMX monitoring using Tomcat 7.0.54.  Turning on the
JMX monitoring is not the problem. To do this I added the following to the
Apache Tomcat 7.0 Properties 'JAVA' tab  GUI Window, which opens up when
you run 'TOMCAT7w.exe //ES/', and it works in that JMX can
monitor it.

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8555
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=


The problem is that when I go to STOP the Service it gives me the following
error

Error: Exception thrown by the agent : java.rmi.server.ExportException:
Port already in use: 8555; nested exception is:
   java.net.BindException: Address already in use: JVM_Bind


I have to do a hard kill by either restarting the Appserver or doing SC
QUERY which is not realistic

I can find hits on the error message but the answers seem to relate to the
need to set up JMX under CATALINA_OPTS.  My issue is that I'm struggling to
figure out how to set up CATALINA_OPTS that in Windows when starting Tomcat
using a Service.  The solutions I find either are Linux (I'm Windows) or
talks about setting up JMX with a setenv.bat OR catalina.bat files.
However, from my research the catalina.bat and setenv files are ignored
when you use a Windows Service.

So my question is how do I do I set up CATALINA_OPTS parameter in Tomcat
7.0.54 when I'm using a Windows Service?

Thanks, Louis

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and
may contain information that is confidential, proprietary or exempt from
disclosure. If you are not the intended recipient, please contact the
sender immediately. Unauthorized use or distribution is prohibited and may
be unlawful.
---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s)

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Thanks for the response

>When you say "stop the service" you just mean clicking the "stop service" link 
>in the management snap-in, right?

Correct

>1. You only have a single Tomcat service defined.
>2. It starts up just fine.
> 3. It only fails when trying to stop it.

Correct

> Do you have any opportunities for upgrading to 7.0.latest?

I have a sandbox where I can try that but it might cause issues with the 
application I'm running with Tomcat.  I will try to try this within the next 
week and let you know.



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, August 02, 2018 5:04 PM
To: users@tomcat.apache.org
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/2/18 3:58 PM, Louis Zipes wrote:
> Hi All, I'm trying to enable JMX monitoring using Tomcat 7.0.54.
> Turning on the JMX monitoring is not the problem. To do this I
> added the following to the Apache Tomcat 7.0 Properties 'JAVA' tab
> GUI Window, which opens up when you run 'TOMCAT7w.exe //ES/ name>', and it works in that JMX can monitor it.
>
> -Djava.rmi.server.hostname=localhost
> -Dcom.sun.management.jmxremote.port=8555
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dcom.sun.management.jmxremote.ssl=

Congratulations on getting that working. Sometimes it can be a pain to
get JMX working.

FWIW, I always recommend using the JMX Proxy Servlet[1] because (a)
you don't have to set up a remote-JMX port and (b) deal with the poor
authentication support and (c) launch a whole JVM process just to take
a quick sample.

> The problem is that when I go to STOP the Service it gives me the
> following error
>
> Error: Exception thrown by the agent :
> java.rmi.server.ExportException: Port already in use: 8555; nested
> exception is: java.net.BindException: Address already in use:
> JVM_Bind

Yuck.

When you say "stop the service" you just mean clicking the "stop
service" link in the management snap-in, right?

Hrm.

> I have to do a hard kill by either restarting the Appserver or
> doing SC QUERY which is not realistic
>
> I can find hits on the error message but the answers seem to
> relate to the need to set up JMX under CATALINA_OPTS.

Yeah, that's usually because someone is using the scripts like
catalina.sh (*NIX) or catalina.bat to launch (and stop) Tomcat and
they have used JAVA_OPTS (which are applied to all JVM launches) to
set those options instead of CATALINA_OPTS (which only applies to
starting Tomcat, not to stopping it, etc.).

> My issue is that I'm struggling to figure out how to set up
> CATALINA_OPTS that in Windows when starting Tomcat using a
> Service.

Ignore all that. When using the service, the environment variables are
not relevant (after creating the service).

> The solutions I find either are Linux (I'm Windows) or talks about
> setting up JMX with a setenv.bat OR catalina.bat files.
> However, from my research the catalina.bat and setenv files are
> ignored when you use a Windows Service.
Exactly.

> So my question is how do I do I set up CATALINA_OPTS parameter in
> Tomcat 7.0.54 when I'm using a Windows Service?

I'm surprised it's failing at all, honestly.

Can you confirm the following:

1. You only have a single Tomcat service defined.
2. It starts up just fine.
3. It only fails when trying to stop it.

Do you have any opportunities for upgrading to 7.0.latest?

- -chris

[1]
http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html#Using_the_JMXPro
xyServlet
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltjcd0ACgkQHPApP6U8
pFis3g/+Ll/6m4VYpII6IFgJF+weoMn9EZ/3E9zbmN/00b63l2uKgNL9rX5eFRXH
v+8Mt9HLRy3ve+UXQsCE3dbm0Uw974ujjht6HrTr3dt4uTY6pGU1XtJqxUL4aFXF
Ri1xL3CwbO8+lGMNsd7zW80kf9wvcyqDt2NfXKz50Y/EkjiFjPYwVbyO2qWjORx9
JdUGBY7GCyk6E9f/UeEJq1JAWRqX2DAdwOn9l8EQ7ECYpXNyd6Jp7gxO/sIpuEpL
NuyRjIjrqyD/7ob65rTEjhXkWarZi5R88RMPmBJ2sHm+mefZQu1sVjJ47sU6emM4
eTAZVgB8RPdtHwjE2+rfezSnKk0969xF8rvI6ehkbaCJ+0qXNYwcqu2lbRhZrPv/
wMNSBj03NToglihLUfmKDraweH3LBvsUdLDLm/mUZoR44l7pjE55o8fc7bT7rJSM
1lFkPOPlXlWtbNrjIMXdLIaJU4fAh8StwQbIdg9Fxku4k9uo7+kT+w52tFVzGq6u
dlKKG/uYIzmkSbJQBK/C1q4wy7hgi3s3kd5KnymRAXeBva9tPkbUkKlAvNdQVfxN
f5RHdECFF6vL5lLNgcDAHNwRPsQJ2G7nPDdGuoBpf6hQR30jUN7l0nTv/CYYVZY1
0DWlxaVr+/mboIGwOTrB602qKif5FYSuf3WuoogHSuRAueBjBmM=
=gT8A
-END PGP SIGNATURE-

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

---
CONFIDENTIALITY N

RE: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Thanks.  I will try this tomorrow.

-Original Message-
From: Daniel Savard [mailto:daniel.sav...@gmail.com]
Sent: Thursday, August 02, 2018 6:15 PM
To: Tomcat Users List
Subject: Re: Question about setting CATALINA_OPTS when starting Tomcat using a 
Windows Service in Tomcat 7.0.54

- - - external message, proceed with caution - - -


In ${Tomcat}/conf create the file management.properties and put your stuff
in this file like:

com.sun.management.jmxremote = true
com.sun.management.jmxremote.port = 9876
com.sun.management.registry.ssl =true
com.sun.management.ssl = true
com.sun.management.ssl.enebled.protocols = TLSv1.2
...

Then, remove your stuff from the CATALINA_OPTS and just point to this file
with
-Dcom.sun.management.config.file=${CATALINA_BASE}/conf/management.properties
and you port in use message will disappear since this configuration will be
handled properly.

Regards,

Le 2 août 2018 3:58 PM, "Louis Zipes"  a écrit :

Hi All,
I'm trying to enable JMX monitoring using Tomcat 7.0.54.  Turning on the
JMX monitoring is not the problem. To do this I added the following to the
Apache Tomcat 7.0 Properties 'JAVA' tab  GUI Window, which opens up when
you run 'TOMCAT7w.exe //ES/', and it works in that JMX can
monitor it.

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8555
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=


The problem is that when I go to STOP the Service it gives me the following
error

Error: Exception thrown by the agent : java.rmi.server.ExportException:
Port already in use: 8555; nested exception is:
   java.net.BindException: Address already in use: JVM_Bind


I have to do a hard kill by either restarting the Appserver or doing SC
QUERY which is not realistic

I can find hits on the error message but the answers seem to relate to the
need to set up JMX under CATALINA_OPTS.  My issue is that I'm struggling to
figure out how to set up CATALINA_OPTS that in Windows when starting Tomcat
using a Service.  The solutions I find either are Linux (I'm Windows) or
talks about setting up JMX with a setenv.bat OR catalina.bat files.
However, from my research the catalina.bat and setenv files are ignored
when you use a Windows Service.

So my question is how do I do I set up CATALINA_OPTS parameter in Tomcat
7.0.54 when I'm using a Windows Service?

Thanks, Louis

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and
may contain information that is confidential, proprietary or exempt from
disclosure. If you are not the intended recipient, please contact the
sender immediately. Unauthorized use or distribution is prohibited and may
be unlawful.
---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Daniel Savard]

In ${Tomcat}/conf create the file management.properties and put your stuff
in this file like:

com.sun.management.jmxremote = true
com.sun.management.jmxremote.port = 9876
com.sun.management.registry.ssl =true
com.sun.management.ssl = true
com.sun.management.ssl.enebled.protocols = TLSv1.2
...

Then, remove your stuff from the CATALINA_OPTS and just point to this file
with
-Dcom.sun.management.config.file=${CATALINA_BASE}/conf/management.properties
and you port in use message will disappear since this configuration will be
handled properly.

Regards,

Le 2 août 2018 3:58 PM, "Louis Zipes"  a écrit :

Hi All,
I'm trying to enable JMX monitoring using Tomcat 7.0.54.  Turning on the
JMX monitoring is not the problem. To do this I added the following to the
Apache Tomcat 7.0 Properties 'JAVA' tab  GUI Window, which opens up when
you run 'TOMCAT7w.exe //ES/', and it works in that JMX can
monitor it.

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8555
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=


The problem is that when I go to STOP the Service it gives me the following
error

Error: Exception thrown by the agent : java.rmi.server.ExportException:
Port already in use: 8555; nested exception is:
   java.net.BindException: Address already in use: JVM_Bind


I have to do a hard kill by either restarting the Appserver or doing SC
QUERY which is not realistic

I can find hits on the error message but the answers seem to relate to the
need to set up JMX under CATALINA_OPTS.  My issue is that I'm struggling to
figure out how to set up CATALINA_OPTS that in Windows when starting Tomcat
using a Service.  The solutions I find either are Linux (I'm Windows) or
talks about setting up JMX with a setenv.bat OR catalina.bat files.
However, from my research the catalina.bat and setenv files are ignored
when you use a Windows Service.

So my question is how do I do I set up CATALINA_OPTS parameter in Tomcat
7.0.54 when I'm using a Windows Service?

Thanks, Louis

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and
may contain information that is confidential, proprietary or exempt from
disclosure. If you are not the intended recipient, please contact the
sender immediately. Unauthorized use or distribution is prohibited and may
be unlawful.

Re: Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Louis,

On 8/2/18 3:58 PM, Louis Zipes wrote:
> Hi All, I'm trying to enable JMX monitoring using Tomcat 7.0.54.
> Turning on the JMX monitoring is not the problem. To do this I
> added the following to the Apache Tomcat 7.0 Properties 'JAVA' tab
> GUI Window, which opens up when you run 'TOMCAT7w.exe //ES/ name>', and it works in that JMX can monitor it.
> 
> -Djava.rmi.server.hostname=localhost 
> -Dcom.sun.management.jmxremote.port=8555 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dcom.sun.management.jmxremote.ssl=

Congratulations on getting that working. Sometimes it can be a pain to
get JMX working.

FWIW, I always recommend using the JMX Proxy Servlet[1] because (a)
you don't have to set up a remote-JMX port and (b) deal with the poor
authentication support and (c) launch a whole JVM process just to take
a quick sample.

> The problem is that when I go to STOP the Service it gives me the
> following error
> 
> Error: Exception thrown by the agent :
> java.rmi.server.ExportException: Port already in use: 8555; nested
> exception is: java.net.BindException: Address already in use:
> JVM_Bind

Yuck.

When you say "stop the service" you just mean clicking the "stop
service" link in the management snap-in, right?

Hrm.

> I have to do a hard kill by either restarting the Appserver or
> doing SC QUERY which is not realistic
> 
> I can find hits on the error message but the answers seem to
> relate to the need to set up JMX under CATALINA_OPTS.

Yeah, that's usually because someone is using the scripts like
catalina.sh (*NIX) or catalina.bat to launch (and stop) Tomcat and
they have used JAVA_OPTS (which are applied to all JVM launches) to
set those options instead of CATALINA_OPTS (which only applies to
starting Tomcat, not to stopping it, etc.).

> My issue is that I'm struggling to figure out how to set up
> CATALINA_OPTS that in Windows when starting Tomcat using a
> Service.

Ignore all that. When using the service, the environment variables are
not relevant (after creating the service).

> The solutions I find either are Linux (I'm Windows) or talks about 
> setting up JMX with a setenv.bat OR catalina.bat files.
> However, from my research the catalina.bat and setenv files are
> ignored when you use a Windows Service.
Exactly.

> So my question is how do I do I set up CATALINA_OPTS parameter in 
> Tomcat 7.0.54 when I'm using a Windows Service?

I'm surprised it's failing at all, honestly.

Can you confirm the following:

1. You only have a single Tomcat service defined.
2. It starts up just fine.
3. It only fails when trying to stop it.

Do you have any opportunities for upgrading to 7.0.latest?

- -chris

[1]
http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html#Using_the_JMXPro
xyServlet
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltjcd0ACgkQHPApP6U8
pFis3g/+Ll/6m4VYpII6IFgJF+weoMn9EZ/3E9zbmN/00b63l2uKgNL9rX5eFRXH
v+8Mt9HLRy3ve+UXQsCE3dbm0Uw974ujjht6HrTr3dt4uTY6pGU1XtJqxUL4aFXF
Ri1xL3CwbO8+lGMNsd7zW80kf9wvcyqDt2NfXKz50Y/EkjiFjPYwVbyO2qWjORx9
JdUGBY7GCyk6E9f/UeEJq1JAWRqX2DAdwOn9l8EQ7ECYpXNyd6Jp7gxO/sIpuEpL
NuyRjIjrqyD/7ob65rTEjhXkWarZi5R88RMPmBJ2sHm+mefZQu1sVjJ47sU6emM4
eTAZVgB8RPdtHwjE2+rfezSnKk0969xF8rvI6ehkbaCJ+0qXNYwcqu2lbRhZrPv/
wMNSBj03NToglihLUfmKDraweH3LBvsUdLDLm/mUZoR44l7pjE55o8fc7bT7rJSM
1lFkPOPlXlWtbNrjIMXdLIaJU4fAh8StwQbIdg9Fxku4k9uo7+kT+w52tFVzGq6u
dlKKG/uYIzmkSbJQBK/C1q4wy7hgi3s3kd5KnymRAXeBva9tPkbUkKlAvNdQVfxN
f5RHdECFF6vL5lLNgcDAHNwRPsQJ2G7nPDdGuoBpf6hQR30jUN7l0nTv/CYYVZY1
0DWlxaVr+/mboIGwOTrB602qKif5FYSuf3WuoogHSuRAueBjBmM=
=gT8A
-END PGP SIGNATURE-

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

Question about setting CATALINA_OPTS when starting Tomcat using a Windows Service in Tomcat 7.0.54

[Louis Zipes]

Hi All,
I'm trying to enable JMX monitoring using Tomcat 7.0.54.  Turning on the JMX 
monitoring is not the problem. To do this I added the following to the Apache 
Tomcat 7.0 Properties 'JAVA' tab  GUI Window, which opens up when you run 
'TOMCAT7w.exe //ES/', and it works in that JMX can monitor it.

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8555
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=


The problem is that when I go to STOP the Service it gives me the following 
error

Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
already in use: 8555; nested exception is:
   java.net.BindException: Address already in use: JVM_Bind


I have to do a hard kill by either restarting the Appserver or doing SC QUERY 
which is not realistic

I can find hits on the error message but the answers seem to relate to the need 
to set up JMX under CATALINA_OPTS.  My issue is that I'm struggling to figure 
out how to set up CATALINA_OPTS that in Windows when starting Tomcat using a 
Service.  The solutions I find either are Linux (I'm Windows) or talks about 
setting up JMX with a setenv.bat OR catalina.bat files.However, from my 
research the catalina.bat and setenv files are ignored when you use a Windows 
Service.

So my question is how do I do I set up CATALINA_OPTS parameter in Tomcat 7.0.54 
when I'm using a Windows Service?

Thanks, Louis

---
CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure. If you are not the intended recipient, please contact the sender 
immediately. Unauthorized use or distribution is prohibited and may be unlawful.

Re: from apache-tomcat-7.0.54 to apache-tomcat-7.0.78 performance issues

[afattahi]

Dear markt,

I try o use them and generate some reports. Meanwhile I found that after
upgrade the server CPU and Memeory usage dose not change but the server
response time drop down, even static resources (like .css and .js) files
take too long to download.

Thanks!



--
View this message in context: 
http://tomcat.10.x6.nabble.com/from-apache-tomcat-7-0-54-to-apache-tomcat-7-0-78-performance-issues-tp5064561p5064744.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Re: from apache-tomcat-7.0.54 to apache-tomcat-7.0.78 performance issues

[afattahi]

Dear Taichi, I have not change any log level during this update, where (
which file) should I check



--
View this message in context: 
http://tomcat.10.x6.nabble.com/from-apache-tomcat-7-0-54-to-apache-tomcat-7-0-78-performance-issues-tp5064561p5064743.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Re: from apache-tomcat-7.0.54 to apache-tomcat-7.0.78 performance issues

[Taiichi Fujiwara]

How about change log level?

Taichi

2017-06-20 22:36 GMT+09:00 Mark Thomas <ma...@apache.org>:

> On 20/06/2017 13:45, Alireza Fattahi wrote:
> > We switched from apache-tomcat-7.0.54 to apache-tomcat-7.0.78, after
> that we face slow loading if the site, even site first page
> >
> > We are using tomcat datasource.
> > We did not change any application or tomcat parameter during this
> upgrade.
> >
> >
> > Any comments? ~Regards,
>
> Use a profiler.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: from apache-tomcat-7.0.54 to apache-tomcat-7.0.78 performance issues

[Mark Thomas]

On 20/06/2017 13:45, Alireza Fattahi wrote:
> We switched from apache-tomcat-7.0.54 to apache-tomcat-7.0.78, after that we 
> face slow loading if the site, even site first page
> 
> We are using tomcat datasource.
> We did not change any application or tomcat parameter during this upgrade.
> 
> 
> Any comments? ~Regards,

Use a profiler.

Mark

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

from apache-tomcat-7.0.54 to apache-tomcat-7.0.78 performance issues

[Alireza Fattahi]

We switched from apache-tomcat-7.0.54 to apache-tomcat-7.0.78, after that we 
face slow loading if the site, even site first page

We are using tomcat datasource.
We did not change any application or tomcat parameter during this upgrade.


Any comments? ~Regards,
~~Alireza Fattahi

Re: tomcat 7.0.54 /jdk 1.8 - only TLS_RSA_* ciphers work

[Mark Thomas]

On 01/11/2016 20:40, Christopher Schultz wrote:
> Daba,
> 
> On 11/1/16 4:33 PM, capt.spock wrote:
>> Stumped with this issue...environment tomcat 7.054 with openjdk
>> version "1.8.0_111" OpenJDK Runtime Environment (build
>> 1.8.0_111-b15)
> 
>> Couple of servers with below config in server.xml throws warning
>> in Catalina and browsers have issue connecting.
> 



>> Any pointers will help in troubleshooting this issue.
> 
> Does this discussion help at all?
> 
> http://markmail.org/thread/fefvkflhzfaqom2m

In addition to Chris's hint, this might help you confirm what is happening:

http://people.apache.org/~markt/dev/TLSInfo.java

Mark

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

Re: tomcat 7.0.54 /jdk 1.8 - only TLS_RSA_* ciphers work

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daba,

On 11/1/16 4:33 PM, capt.spock wrote:
> Stumped with this issue...environment tomcat 7.054 with openjdk
> version "1.8.0_111" OpenJDK Runtime Environment (build
> 1.8.0_111-b15)
> 
> Couple of servers with below config in server.xml throws warning
> in Catalina and browsers have issue connecting.
> 
>  protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150"
> SSLEnabled="true" scheme="https" secure="true" clientAuth="false"
> sslProtocol="TLS" sslEnabledProtocols="TLSv1.2"
> 
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AE
S_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WIT
H_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_
WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WI
TH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA
_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_EC
DSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_E
CDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_
ECDSA_WITH_AES_128_CBC_SHA"
>
> 
/>
> 
> INFO: The APR based Apache Tomcat Native library which allows
> optimal performance in production environments was not found on
> the java.library.path: 
> /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib Nov
> 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init INFO:
> Initializing ProtocolHandler ["http-bio-8080"] Nov 01, 2016 1:15:39
> PM org.apache.coyote.AbstractProtocol init INFO: Initializing
> ProtocolHandler ["http-bio-8443"] Nov 01, 2016 1:15:39 PM
> org.apache.tomcat.util.net.jsse.JSSESocketFactory 
> getEnableableCiphers WARNING: None of the ciphers specified are
> supported by the SSL engine : 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM
_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128
_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_
256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_25
6_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES
_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_
AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH
_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WIT
H_AES_128_CBC_SHA
>
> 
Nov 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["ajp-bio-8009"] Nov 01, 2016
> 1:15:39 PM org.apache.coyote.AbstractProtocol init INFO:
> Initializing ProtocolHandler ["http-bio-9443"] Nov 01, 2016 1:15:39
> PM org.apache.coyote.AbstractProtocol init INFO: Initializing
> ProtocolHandler ["ajp-bio-9009"] Nov 01, 2016 1:15:39 PM
> org.apache.catalina.startup.Catalina load INFO: Initialization
> processed in 567 ms Nov 01, 2016 1:15:39 PM
> org.apache.catalina.core.StandardService startInternal INFO:
> Starting service Catalina Nov 01, 2016 1:15:39 PM
> org.apache.catalina.core.StandardEngine startInternal INFO:
> Starting Servlet Engine: Apache Tomcat/7.0.54
> 
> Any pointers will help in troubleshooting this issue.

Does this discussion help at all?

http://markmail.org/thread/fefvkflhzfaqom2m

Obligatory lists.a.o link:
https://lists.apache.org/thread.html/df063b1d0e86985c01dabf89a3152faf155
4047f7b120b5b7ec3b0a5@%3Cusers.tomcat.apache.org%3E

(I'm not yet a fan of lists.a.o when compared to markmail... sorry, guys
.)

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

iQIcBAEBCAAGBQJYGP2yAAoJEBzwKT+lPKRYnn8P/in5/kBxgj+OkMSlph7kWEWn
/RoElMnW0ZwPJz/62cXJ2ilaAONngwNYZbjbmcag2+JsgNlU1ZhRkUkK/Ux7EEdn
5JDbuw+kleseZ/9oStY/M6EJxoT2PjUmqC774ub28riJTFzokwIPQpPez/L5D7rs
KOc0zGq2SFXnDTmRa0qRYFWwx6IiV6wc2ifdJtPQNvbnedNtWEkVPZCiKB4KVpZZ
f67hNnv2TH+tic6VOhaw2kDj1sSeSHfnTwGY9ti1ml4x129zfhpnX41Mx/m9eoiC
pCQV1+ojCstM5CaK/jiSgx/qpLYdlZFw50oKdEubXH6mRrJ1qTj5XJlyf2oSczGH
VRpH3j+1S+NXZDihu8OYwjJPgHgiXuHBeP+t92UE2+JrVZ4ke+J+31RuMOsTEaP3
i6SFln8D0Cc7qUNxHlV5hvSunz3rtTiPvrY28dZeqDFY8eR2uf6woNV3MsCfIm4V
p4I1b0JWyD/XzZLDQH16rruWTzalZKzMC+Xa1PWT+sWr8wTm5MoT2c9p9p4hV+fS
Slj9P+fesk5djxfZojC/d1H+Nj5AHtXQFponng8CSi/jnm7L3JSQ1O9u9Ok8bD87
9HJl5tH7wKC0gj4XTxtt21nmcrZm6NNugqjZDqSyTqyzppu9rSVS9vewB65PuAgP
Ct/U6RLxz5z/EfYfnQOH
=jhXr
-END PGP SIGNATURE-

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

tomcat 7.0.54 /jdk 1.8 - only TLS_RSA_* ciphers work

[capt.spock]

Stumped with this issue...environment tomcat 7.054 with openjdk version
"1.8.0_111" OpenJDK Runtime Environment (build 1.8.0_111-b15)

Couple of servers with below config in server.xml throws warning in
Catalina and browsers have issue connecting.



INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Nov 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Nov 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8443"]
Nov 01, 2016 1:15:39 PM org.apache.tomcat.util.net.jsse.JSSESocketFactory
getEnableableCiphers
WARNING: None of the ciphers specified are supported by the SSL engine :
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
Nov 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Nov 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-9443"]
Nov 01, 2016 1:15:39 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-9009"]
Nov 01, 2016 1:15:39 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 567 ms
Nov 01, 2016 1:15:39 PM org.apache.catalina.core.StandardService
startInternal
INFO: Starting service Catalina
Nov 01, 2016 1:15:39 PM org.apache.catalina.core.StandardEngine
startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.54

Any pointers will help in troubleshooting this issue.

Thanks!
Daba

Re: Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 8/4/16 9:19 PM, David Kerber wrote:
> On 8/4/2016 3:18 AM, Rahul Singh wrote:
>> Dear Christopher,
>> 
>> 
>> Thanks you very much for your response !!
>> 
>> 
>>> Filesystem quota?
>> 
>> Filesystem Quota is not enabled for this disk partition so there
>> is no restrictions on disk usage.
>> 
>> 
>>> Look at the timestamps on the zero-byte files, then find that
>>> same place in catalina.out or one of the other Tomcat-specific
>>> log files. See if there's anything in those log files that
>>> gives a reason for the failure to compile your JSPs.
>> 
>> We have seen the catlina.out and other tomcat logs but no such 
>> evidence regarding the compilation of JSP.
>> 
>> 
>> during googling in various forums, we have observed that the
>> same problem is occurred to one of the senior engineer of google,
>> and it is unresolved/open yet.
>> 
>> 
>> reference: 
>> http://stackoverflow.com/questions/8813509/how-does-tomcat-generate-i
ts-work-directory-jsp-java-files-and-what-might-cau
>>
>>
>>
>>
>> 
It is very critical problem in our production environments (occurring
>> Many production environments),  and it is raised as tomcat
>> specific problem so occurrence condition and root cause may be
>> required from tomcat team.
> 
> Have you verified that the user TC is running under has permissions
> to write to the directories in question?

Tomcat wouldn't be able to write zero-byte files if there were
file-permissions problems.

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

iQIcBAEBCAAGBQJXqgiRAAoJEBzwKT+lPKRYWSgQAMt6CBuAYul5JQpiN2GjTk8b
azl4sV/l10O20US4TmxHHK5s7qhkApQPI/Au+NIkwJ9JzJgGcrvyln9tXoiF5NnB
bkS4ac42/z90nW2XJrMAb5yOr5GT8whSu3jvS2z1uZS2/iOnDzkuJ+fzisZeaWtp
FtG+KXw28+2TqPUusiZzAiJZaE71YThl9EtgLb7Rd3aeUbokcH8pzj149n2XxpJ+
6YdbgePJhw0Kej3MHlDp9IgfRo/heD3ogr2MgXdxiUTj1CooabHlmSQFVyhITN7e
XkRjFK8liqIcXO7YlbX4xDMS479lgYFHY5I2I6dwqZKIF4AjhvVjijLUap9pnwlf
gtDjjILU8YtOCudIhsLc0k6i4VIwuYLeFkvg0wIq6LmTrpLoPmgfWQB1uMBPrJn+
9dfjiIbsJlDqEMwyN/dRjq3XOXEQiljTx6nWuZOJeCd2SQ2fX///GLQfgvbKH6TN
km6wD3SKWV1dW9qn2tf1M3hVvPZq5FO6LCWuFxNUo1skucQrKCcH1UoU3swEpCQu
smWGacd20ahYKF1WAb94TY/wX/K0BI8I2pgO5C6LsktVZpgLCOeFc7Kn+s01Ww6x
24zdBp2xM4PB3hsXT+QpKqLhBSDjRQCYC09yOTh0+BM2ibXg+Fh13fIePzk7rQ/Y
j9ROIfCeqpLo/rc3b5t9
=6zpP
-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.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[David Kerber]

On 8/4/2016 3:18 AM, Rahul Singh wrote:

Dear Christopher,


Thanks you very much for your response !!



Filesystem quota?


Filesystem Quota is not enabled for this disk partition so there is no 
restrictions on disk usage.



Look at the timestamps on the zero-byte files, then find that same
place in catalina.out or one of the other Tomcat-specific log files.
See if there's anything in those log files that gives a reason for the
failure to compile your JSPs.


We have seen the catlina.out and other tomcat logs but no such evidence 
regarding the compilation of JSP.


during googling in various forums, we have observed that the same problem is 
occurred to one of the senior engineer of google, and it is unresolved/open yet.


reference: 
http://stackoverflow.com/questions/8813509/how-does-tomcat-generate-its-work-directory-jsp-java-files-and-what-might-cau


It is very critical problem in our production environments (occurring Many 
production environments),  and it is raised as tomcat specific problem so 
occurrence condition and root cause may be required from tomcat team.


Have you verified that the user TC is running under has permissions to 
write to the directories in question?







Regards,

Rahul Kumar Singh







From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Sunday, July 31, 2016 5:38:13 PM
To: Tomcat Users List
Subject: Re: Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in 
work directory that cause truncated class error

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 7/28/16 1:50 AM, Rahul Singh wrote:

Hi tomcat team, Thanks for your continued support and help.

I am facing the a peculiar problem in Tomcat 7.0.54.

Any chance for a Tomcat upgrade? Also, Java 7 has reached End-of-Life.


Configurations: OS: RHEL Tomcat:7.0.54 Java:1.7.79

If you are using RHEL packages, you may not have an upgrade path. :(


A jsp that was running properly gave the following exception after
graceful tomcat restart

 javax.servlet.ServletException:
java.lang.ClassFormatError: Truncated class file at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli

cationFilterChain.java:303)



at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:208)

at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)



at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:241)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi

lterChain.java:208)



at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
her.java:748)

at
org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicat

ionDispatcher.java:486)



at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
atcher.java:411)

at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDisp

atcher.java:338)



at
org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletD
ispatcherResult.java:154)

at
org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResult

Support.java:186)



at
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultAct
ionInvocation.java:362)

at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionIn

vocation.java:266)

  

On checking the Tomcat work directory we discovered that the
corresponding .java and .class files were of zero byte size. In
other words these files were empty. This was the main reason why
Tomcat gave truncated class error. Corresponding to this we also
checked the disk utilization but it was at 54% only. So any
possibility for disk space are ruled out.

Filesystem quota?


Also that the same jsp had not been modified and was running
properly initially. so after reboot of tomcat what happen? why the
jsp.java and jsp.class size is generated of 0 bytes.

So my question is that what might have caused tomcat to generate
empty *_jsp.java files in its work directory?

Hope tomcat team will help us to finding root cause.

Look at the timestamps on the zero-byte files, then find that same
place in catalina.out or one of the other Tomcat-specific log files.
See if there's anything in those log files that gives a reason for the
failure to compile your JSPs.

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

iEYEARECAAYFAled6i0ACgkQ9CaO5/Lv0PB59ACePn8ro2YsATZjgDFh8lTH1dU/
T5YAnjxaL4LZB4BdfL/wTJuPEeBfT4fh
=pvZ5
-END PGP SIGNATURE-

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

Re: Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[Rahul Singh]

Dear Christopher,


Thanks you very much for your response !!


>Filesystem quota?


Filesystem Quota is not enabled for this disk partition so there is no 
restrictions on disk usage.


>Look at the timestamps on the zero-byte files, then find that same
>place in catalina.out or one of the other Tomcat-specific log files.
>See if there's anything in those log files that gives a reason for the
>failure to compile your JSPs.


We have seen the catlina.out and other tomcat logs but no such evidence 
regarding the compilation of JSP.


during googling in various forums, we have observed that the same problem is 
occurred to one of the senior engineer of google, and it is unresolved/open yet.


reference: 
http://stackoverflow.com/questions/8813509/how-does-tomcat-generate-its-work-directory-jsp-java-files-and-what-might-cau


It is very critical problem in our production environments (occurring Many 
production environments),  and it is raised as tomcat specific problem so 
occurrence condition and root cause may be required from tomcat team.



Regards,

Rahul Kumar Singh







From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Sunday, July 31, 2016 5:38:13 PM
To: Tomcat Users List
Subject: Re: Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in 
work directory that cause truncated class error

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 7/28/16 1:50 AM, Rahul Singh wrote:
> Hi tomcat team, Thanks for your continued support and help.
>
> I am facing the a peculiar problem in Tomcat 7.0.54.

Any chance for a Tomcat upgrade? Also, Java 7 has reached End-of-Life.

> Configurations: OS: RHEL Tomcat:7.0.54 Java:1.7.79

If you are using RHEL packages, you may not have an upgrade path. :(

> A jsp that was running properly gave the following exception after
> graceful tomcat restart
>
>  javax.servlet.ServletException:
> java.lang.ClassFormatError: Truncated class file at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:303)
>
>
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>
>
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:208)
>
>
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
her.java:748)
> at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicat
ionDispatcher.java:486)
>
>
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
atcher.java:411)
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDisp
atcher.java:338)
>
>
at
org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletD
ispatcherResult.java:154)
> at
> org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResult
Support.java:186)
>
>
at
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultAct
ionInvocation.java:362)
> at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionIn
vocation.java:266)
>
>  
>
> On checking the Tomcat work directory we discovered that the
> corresponding .java and .class files were of zero byte size. In
> other words these files were empty. This was the main reason why
> Tomcat gave truncated class error. Corresponding to this we also
> checked the disk utilization but it was at 54% only. So any
> possibility for disk space are ruled out.

Filesystem quota?

> Also that the same jsp had not been modified and was running
> properly initially. so after reboot of tomcat what happen? why the
> jsp.java and jsp.class size is generated of 0 bytes.
>
> So my question is that what might have caused tomcat to generate
> empty *_jsp.java files in its work directory?
>
> Hope tomcat team will help us to finding root cause.

Look at the timestamps on the zero-byte files, then find that same
place in catalina.out or one of the other Tomcat-specific log files.
See if there's anything in those log files that gives a reason for the
failure to compile your JSPs.

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

iEYEARECAAYFAled6i0ACgkQ9CaO5/Lv0PB59ACePn8ro2YsATZjgDFh8lTH1dU/
T5YAnjxaL4LZB4BdfL/wTJuPEeBfT4fh
=pvZ5
-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.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 7/28/16 1:50 AM, Rahul Singh wrote:
> Hi tomcat team, Thanks for your continued support and help.
> 
> I am facing the a peculiar problem in Tomcat 7.0.54.

Any chance for a Tomcat upgrade? Also, Java 7 has reached End-of-Life.

> Configurations: OS: RHEL Tomcat:7.0.54 Java:1.7.79

If you are using RHEL packages, you may not have an upgrade path. :(

> A jsp that was running properly gave the following exception after
> graceful tomcat restart
> 
>  javax.servlet.ServletException:
> java.lang.ClassFormatError: Truncated class file at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343) 
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:303)
>
> 
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>
> 
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:208)
>
> 
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
her.java:748)
> at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicat
ionDispatcher.java:486)
>
> 
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
atcher.java:411)
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDisp
atcher.java:338)
>
> 
at
org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletD
ispatcherResult.java:154)
> at
> org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResult
Support.java:186)
>
> 
at
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultAct
ionInvocation.java:362)
> at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionIn
vocation.java:266)
>
>  
> 
> On checking the Tomcat work directory we discovered that the
> corresponding .java and .class files were of zero byte size. In
> other words these files were empty. This was the main reason why
> Tomcat gave truncated class error. Corresponding to this we also
> checked the disk utilization but it was at 54% only. So any
> possibility for disk space are ruled out.

Filesystem quota?

> Also that the same jsp had not been modified and was running
> properly initially. so after reboot of tomcat what happen? why the
> jsp.java and jsp.class size is generated of 0 bytes.
> 
> So my question is that what might have caused tomcat to generate
> empty *_jsp.java files in its work directory?
> 
> Hope tomcat team will help us to finding root cause.

Look at the timestamps on the zero-byte files, then find that same
place in catalina.out or one of the other Tomcat-specific log files.
See if there's anything in those log files that gives a reason for the
failure to compile your JSPs.

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

iEYEARECAAYFAled6i0ACgkQ9CaO5/Lv0PB59ACePn8ro2YsATZjgDFh8lTH1dU/
T5YAnjxaL4LZB4BdfL/wTJuPEeBfT4fh
=pvZ5
-END PGP SIGNATURE-

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

Tomcat 7.0.54 gives zero-byte .java and .class files for jsp in work directory that cause truncated class error

[Rahul Singh]

Hi tomcat team,
Thanks for your continued support and help.

I am facing the a peculiar problem in Tomcat 7.0.54.

Configurations:
OS: RHEL
Tomcat:7.0.54
Java:1.7.79


A jsp that was running properly gave the following exception after graceful 
tomcat restart


javax.servlet.ServletException: java.lang.ClassFormatError: Truncated class file
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)
at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:486)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:411)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:338)
at 
org.apache.struts2.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:154)
at 
org.apache.struts2.dispatcher.StrutsResultSupport.execute(StrutsResultSupport.java:186)
at 
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362)
at 
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266)



On checking the Tomcat work directory we discovered that the corresponding 
.java and .class files were of zero byte size.
In other words these files were empty. This was the main reason why Tomcat gave 
truncated class error.
Corresponding to this we also checked the disk utilization but it was at 54% 
only. So any possibility for disk space
are ruled out.
Also that the same jsp had not been modified and was running properly 
initially. so after reboot of tomcat
what happen? why the jsp.java and jsp.class size is generated of 0 bytes.

So my question is that what might have caused tomcat to generate empty 
*_jsp.java files in its work directory?

Hope tomcat team will help us to finding root cause.

Regards,
Rahul Kumar singh

RE: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Alten, Jessica-Aileen]

> We have used HTTP Analayzer for file upload via Internet Explorer-8.
> Following are the scenario observed. [...]

I've just came back from vacation and didn't followed the whole thread - but I 
think it is simply an IE 8 problem, see 
http://blogs.msdn.com/b/ieinternals/archive/2011/03/10/wininet-internet-explorer-file-download-and-upload-maximum-size-limits.aspx

IE 8 can't upload more than 2 GB.

Greetings
Jessica


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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Apart from below information, one additional information.

We have used the jQuery form plugin js in our project. This handles the form 
and request submit. The code is as attached here.





From: Rahul Singh <rksing...@hotmail.com>
Sent: Tuesday, January 19, 2016 11:30 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Hi Christopher ,


>>So... what makes you sure that the browser actually made the request?
>>I'd like to see some kind of confirmation using a tool you didn't
>>write. Perhaps something like Firebug, LiveHttpHeaders, Fiddler, or
>>even Wireshark showing that the request was made, what headers it had,
>>etc.

OK,
We have used HTTP Analayzer for file upload via Internet Explorer-8. Following 
are the scenario observed.

For lesser than 2gb file uploads : The request header shows the correct 
content-length value of the file.The uploads works fine further also.

For more than 2gb file uploads: The file length is 2151533567 bytes(which is 
roughly 2.15 Gb).  The request is aborted in this case and the request header 
shows the content length
as -214343325 bytes (which is rougly 214 Mb).The upload process does not 
proceed further in this case.

both cases request headers are attached in screenshot.

From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, January 18, 2016 11:17 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/17/16 11:28 PM, Rahul Singh wrote:
> Code flow is attached, forgot to attach in trailing mail.
>
> --
- --
>
>
*From:* Rahul Singh <rksing...@hotmail.com>
> *Sent:* Monday, January 18, 2016 8:39 AM *To:* Tomcat Users List
> *Subject:* Re: File size >= 2GB not uploaded in application
> [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> Hello Christopher, thanks for your prompt response !!
>
>> Why didn't you come to the Tomcat community first?
> Sorry for the delay, we wanted to make sure about the component
> causing the problem.
>
>
>>> I don't have a test-case in front of me, but I'm fairly
>>> confident that Tomcat allows file uploads of greater than 2GiB.
>>> I suspect the problem
> is another component.
>>> Are you using Servlet 3.0-based file upload, or are you
>>> allowing Struts to handle the file-upload for you? If you use
>>> Servlet-3.0 file-upload, then you'll have code that deals with
>>> Multipart classes and configuration in web.xml. If you are
>>> using Struts's file-upload, then you'll mostly just be calling
>>> getFile or getInputStream or however Struts 2 does things (I
>>> can't remember how it all works off the top of my head).
>
>
> In our case the filter class implements the javax.servlet.flter
> and imports javax.servlet.* The Filter class mentioned in the
> previous threads is the first one as declared in the web.xml
> (followed by other struts filters). All (url) requests are mapped
> to this filter. So this is where our file upload request goes. It
> is only in greater than 2 gb file upload request that the
> dofilter() fails to get any request. So we feel servlet 3.0 being
> used in our case the Filter is not being able to handle greater
> than 2 gb requests.
>
>
>>> The point is, if you are using Struts, then Tomcat will not
>>> touch the request and Struts is handling the whole thing. If
>>> Struts is the problem, you'll need to talk to the Struts
>>> team[1].
>
>>> If you are using Servlet-3.0 file-upload, then Struts is just a
>>> red herring and this is the right place to get your issue
>>> solved.
>
> As mentioned above Servlet 3.0 is being used. So request the
> tomcat community to please look into our issue.
>
>>> So far, you have posted some configuration for Struts and some
>>> JSP tablib-filled code, plus some Java code for a Filter. You
>>> didn't say where the Filter was in the filter chain (before or
>>> after Struts filter). You also mentioned that the form is
>>> actually posted using XMLHttpRequest and not through a standard
>>> form, but you didn't explain what component is doing that or
>>> how it actually works.
>
>>> There isn't enough information here to make any sense of the
>>> situation. Can you please address all of the questions I've
>>> posed above and maybe we can then help you?
>
>
> <<>>

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/19/16 1:00 AM, Rahul Singh wrote:
>>> So... what makes you sure that the browser actually made the
>>> request? I'd like to see some kind of confirmation using a tool
>>> you didn't write. Perhaps something like Firebug,
>>> LiveHttpHeaders, Fiddler, or even Wireshark showing that the
>>> request was made, what headers it had, etc.
> 
> OK, We have used HTTP Analayzer for file upload via Internet
> Explorer-8. Following are the scenario observed.

Support for MSIE 8 has been dropped worldwide unless you have an
expensive support contract.

> For lesser than 2gb file uploads : The request header shows the 
> correct content-length value of the file. The uploads works fine 
> further also.
> 
> For more than 2gb file uploads: The file length is 2151533567 
> bytes(which is roughly 2.15 Gb). The request is aborted in this
> case and the request header shows the content length as -214343325
> bytes (which is rougly 214 Mb).

The request-header as reported by what? The HTTP analyzer?

- -214343325 is not 214MiB. It's an invalid (negative) size. If you were
to take the absolute value of it and call it a size, it would be ~204MiB
.

> The upload process does not proceed further in this case.

Does the request make it to the Tomcat server?

HTTP defines the Content-Length as a series of one or more digits. No
negatives are allowed. If Tomcat is being spec-pedantic (and I hope it
is), it will treat a negative number as invalid and default to zero
(bytes).

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

> both cases request headers are attached in screenshot.

Non-text attachments are stripped from this list. There was no attachmen
t.

Jessica-Aileen has also replied stating that MSIE8 does not support
file uploads greater than 2GiB.

I think the case is closed, here.

Thanks,
- -chris


>  From: Christopher Schultz
> <ch...@christopherschultz.net> Sent: Monday, January 18, 2016 11:17
> AM To: Tomcat Users List Subject: Re: File size >= 2GB not uploaded
> in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
> 
> Rahul,
> 
> On 1/17/16 11:28 PM, Rahul Singh wrote:
>> Code flow is attached, forgot to attach in trailing mail.
> 
>> -
- -
>
>> 
> -
>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlaeWpIACgkQ9CaO5/Lv0PA6fQCgkS8CZwtxPNuzZCZTaAX8X+69
Mi4AoJC7IMWtk6YrJTuekY8zr9viInQk
=jekN
-END PGP SIGNATURE-

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Kiran Badi]

Hi Chris,

Ok but I had bunch of similar issues with file upload when I had done with
struts 2 and plain J2ee. So thought worth checking.

Maybe JavaScript part might be culprit or  form data of JS might have some
limit on size.and file upload via JS is supported only in last couple of
years.Older browsers relied iframe for uploads.

Yes without all the info it's hard to tell anything for sure.

On Monday, January 18, 2016, Joleen Barker  wrote:

> I am not positive, but I thought the older browsers had a 2GB limit. The
> company I worked for ran in to a similar problem and it was the result of
> the browser. I think Chrome didn't have the issue and IE did. We ended up
> making a note in the Known Issues of the manual about the limitation. This
> is going back awhile though.
>
> -Joleen
>
> On Mon, Jan 18, 2016 at 7:40 AM, Christopher Schultz <
> ch...@christopherschultz.net > wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Kiran,
> >
> > On 1/18/16 1:33 AM, Kiran Badi wrote:
> > > Did you exclude your upload servlet from struts.xml ? By default
> > > struts intercepts all multi part requests and this messes a lot
> > > specially when you have hybrid framework when few modules are plain
> > > j2ee and few are struts 2 or Spring MVc in the same app.
> >
> > OP states that the Filter is placed before Struts. Struts's
> > interceptors fire from within Struts's Filter, so that shouldn't be a
> > problem.
> >
> > > Are you upload less than 2gb file ?
> >
> > I think, ultimately, this is going to be a problem with Javascript,
> > the browser (as yet unnamed), or the OP's code.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlac3UcACgkQ9CaO5/Lv0PDFZQCfRt5WfvmP48UwxfM23FP0l0Uz
> > 1AYAn15i3dRPe7d7nVpEU69VW66eyQnQ
> > =d1St
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> 
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> >
> >
>

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kiran,

On 1/18/16 1:33 AM, Kiran Badi wrote:
> Did you exclude your upload servlet from struts.xml ? By default
> struts intercepts all multi part requests and this messes a lot
> specially when you have hybrid framework when few modules are plain
> j2ee and few are struts 2 or Spring MVc in the same app.

OP states that the Filter is placed before Struts. Struts's
interceptors fire from within Struts's Filter, so that shouldn't be a
problem.

> Are you upload less than 2gb file ?

I think, ultimately, this is going to be a problem with Javascript,
the browser (as yet unnamed), or the OP's code.

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

iEYEARECAAYFAlac3UcACgkQ9CaO5/Lv0PDFZQCfRt5WfvmP48UwxfM23FP0l0Uz
1AYAn15i3dRPe7d7nVpEU69VW66eyQnQ
=d1St
-END PGP SIGNATURE-

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Joleen Barker]

I am not positive, but I thought the older browsers had a 2GB limit. The
company I worked for ran in to a similar problem and it was the result of
the browser. I think Chrome didn't have the issue and IE did. We ended up
making a note in the Known Issues of the manual about the limitation. This
is going back awhile though.

-Joleen

On Mon, Jan 18, 2016 at 7:40 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Kiran,
>
> On 1/18/16 1:33 AM, Kiran Badi wrote:
> > Did you exclude your upload servlet from struts.xml ? By default
> > struts intercepts all multi part requests and this messes a lot
> > specially when you have hybrid framework when few modules are plain
> > j2ee and few are struts 2 or Spring MVc in the same app.
>
> OP states that the Filter is placed before Struts. Struts's
> interceptors fire from within Struts's Filter, so that shouldn't be a
> problem.
>
> > Are you upload less than 2gb file ?
>
> I think, ultimately, this is going to be a problem with Javascript,
> the browser (as yet unnamed), or the OP's code.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlac3UcACgkQ9CaO5/Lv0PDFZQCfRt5WfvmP48UwxfM23FP0l0Uz
> 1AYAn15i3dRPe7d7nVpEU69VW66eyQnQ
> =d1St
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi Christopher ,


>>So... what makes you sure that the browser actually made the request?
>>I'd like to see some kind of confirmation using a tool you didn't
>>write. Perhaps something like Firebug, LiveHttpHeaders, Fiddler, or
>>even Wireshark showing that the request was made, what headers it had,
>>etc.

OK,
We have used HTTP Analayzer for file upload via Internet Explorer-8. Following 
are the scenario observed.

For lesser than 2gb file uploads : The request header shows the correct 
content-length value of the file.The uploads works fine further also.

For more than 2gb file uploads: The file length is 2151533567 bytes(which is 
roughly 2.15 Gb).  The request is aborted in this case and the request header 
shows the content length 
as -214343325 bytes (which is rougly 214 Mb).The upload process does not 
proceed further in this case.

both cases request headers are attached in screenshot.

From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, January 18, 2016 11:17 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/17/16 11:28 PM, Rahul Singh wrote:
> Code flow is attached, forgot to attach in trailing mail.
>
> --
- --
>
>
*From:* Rahul Singh <rksing...@hotmail.com>
> *Sent:* Monday, January 18, 2016 8:39 AM *To:* Tomcat Users List
> *Subject:* Re: File size >= 2GB not uploaded in application
> [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> Hello Christopher, thanks for your prompt response !!
>
>> Why didn't you come to the Tomcat community first?
> Sorry for the delay, we wanted to make sure about the component
> causing the problem.
>
>
>>> I don't have a test-case in front of me, but I'm fairly
>>> confident that Tomcat allows file uploads of greater than 2GiB.
>>> I suspect the problem
> is another component.
>>> Are you using Servlet 3.0-based file upload, or are you
>>> allowing Struts to handle the file-upload for you? If you use
>>> Servlet-3.0 file-upload, then you'll have code that deals with
>>> Multipart classes and configuration in web.xml. If you are
>>> using Struts's file-upload, then you'll mostly just be calling
>>> getFile or getInputStream or however Struts 2 does things (I
>>> can't remember how it all works off the top of my head).
>
>
> In our case the filter class implements the javax.servlet.flter
> and imports javax.servlet.* The Filter class mentioned in the
> previous threads is the first one as declared in the web.xml
> (followed by other struts filters). All (url) requests are mapped
> to this filter. So this is where our file upload request goes. It
> is only in greater than 2 gb file upload request that the
> dofilter() fails to get any request. So we feel servlet 3.0 being
> used in our case the Filter is not being able to handle greater
> than 2 gb requests.
>
>
>>> The point is, if you are using Struts, then Tomcat will not
>>> touch the request and Struts is handling the whole thing. If
>>> Struts is the problem, you'll need to talk to the Struts
>>> team[1].
>
>>> If you are using Servlet-3.0 file-upload, then Struts is just a
>>> red herring and this is the right place to get your issue
>>> solved.
>
> As mentioned above Servlet 3.0 is being used. So request the
> tomcat community to please look into our issue.
>
>>> So far, you have posted some configuration for Struts and some
>>> JSP tablib-filled code, plus some Java code for a Filter. You
>>> didn't say where the Filter was in the filter chain (before or
>>> after Struts filter). You also mentioned that the form is
>>> actually posted using XMLHttpRequest and not through a standard
>>> form, but you didn't explain what component is doing that or
>>> how it actually works.
>
>>> There isn't enough information here to make any sense of the
>>> situation. Can you please address all of the questions I've
>>> posed above and maybe we can then help you?
>
>
> <<>>> We need to model the following code to be told:
> jsp submit of the form How the .js submit it further in
> XmlHttpRequest How the Filter is declared How the web.xml is
> declared
>
>
>> Are you sure the request is even made to the server in these
>> cases?What if the Javascript upload component is failing before
>> it even starts?
>
> Yes the request is made in these cases. We have compared the
> scenari

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/17/16 11:28 PM, Rahul Singh wrote:
> Code flow is attached, forgot to attach in trailing mail.
> 
> --
- --
>
> 
*From:* Rahul Singh <rksing...@hotmail.com>
> *Sent:* Monday, January 18, 2016 8:39 AM *To:* Tomcat Users List 
> *Subject:* Re: File size >= 2GB not uploaded in application
> [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
> 
> Hello Christopher, thanks for your prompt response !!
> 
>> Why didn't you come to the Tomcat community first?
> Sorry for the delay, we wanted to make sure about the component
> causing the problem.
> 
> 
>>> I don't have a test-case in front of me, but I'm fairly
>>> confident that Tomcat allows file uploads of greater than 2GiB.
>>> I suspect the problem
> is another component.
>>> Are you using Servlet 3.0-based file upload, or are you
>>> allowing Struts to handle the file-upload for you? If you use
>>> Servlet-3.0 file-upload, then you'll have code that deals with
>>> Multipart classes and configuration in web.xml. If you are
>>> using Struts's file-upload, then you'll mostly just be calling
>>> getFile or getInputStream or however Struts 2 does things (I
>>> can't remember how it all works off the top of my head).
> 
> 
> In our case the filter class implements the javax.servlet.flter
> and imports javax.servlet.* The Filter class mentioned in the
> previous threads is the first one as declared in the web.xml
> (followed by other struts filters). All (url) requests are mapped
> to this filter. So this is where our file upload request goes. It
> is only in greater than 2 gb file upload request that the
> dofilter() fails to get any request. So we feel servlet 3.0 being
> used in our case the Filter is not being able to handle greater
> than 2 gb requests.
> 
> 
>>> The point is, if you are using Struts, then Tomcat will not
>>> touch the request and Struts is handling the whole thing. If
>>> Struts is the problem, you'll need to talk to the Struts
>>> team[1].
> 
>>> If you are using Servlet-3.0 file-upload, then Struts is just a
>>> red herring and this is the right place to get your issue
>>> solved.
> 
> As mentioned above Servlet 3.0 is being used. So request the
> tomcat community to please look into our issue.
> 
>>> So far, you have posted some configuration for Struts and some
>>> JSP tablib-filled code, plus some Java code for a Filter. You
>>> didn't say where the Filter was in the filter chain (before or
>>> after Struts filter). You also mentioned that the form is
>>> actually posted using XMLHttpRequest and not through a standard
>>> form, but you didn't explain what component is doing that or
>>> how it actually works.
> 
>>> There isn't enough information here to make any sense of the 
>>> situation. Can you please address all of the questions I've
>>> posed above and maybe we can then help you?
> 
> 
> <<>>> We need to model the following code to be told: 
> jsp submit of the form How the .js submit it further in
> XmlHttpRequest How the Filter is declared How the web.xml is
> declared
> 
> 
>> Are you sure the request is even made to the server in these
>> cases?What if the Javascript upload component is failing before
>> it even starts?
> 
> Yes the request is made in these cases. We have compared the
> scenario for greater than 2gb and lesser size file uploads and
> drawn the following inference from it.We have checked the request
> and content length for dofilter() method in our logs. The
> JavaScript is not the culprit in this case. The JavaScript sets the
> AJAX field to success after sending request and thereafter waits
> for response(which is not received in our case). Our application
> works fine for lesser than 2 gb fie uploads but fails for greater
> size files as the request fails to reach the dofilter() method
> after which the request can be forwarded to the requested method.
> 
> 
> 
> Regards, Rahul
> 
>  From: Christopher Schultz
> <ch...@christopherschultz.net> Sent: Saturday, January 16, 2016
> 9:33 AM To: Tomcat Users List Subject: Re: File size >= 2GB not
> uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK
> 1.7.79]
> 
> Rahul,
> 
> On 1/15/16 1:02 AM, Rahul Singh wrote:
>> Thanks for your guidelines, we have big hope from Apache Tomcat 
>> Team to solve this problem as this is show stopper for our 
>> application, we have also 

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Konstantin Kolinko]

2016-01-18 6:09 GMT+03:00 Rahul Singh :
>
>>Are you sure the request is even made to the server in these cases?What if 
>>the Javascript upload component is failing before it even starts?
>
> Yes the request is made in these cases. We have compared the scenario for 
> greater than 2gb and lesser size file uploads and drawn the following 
> inference from it.We have checked the request and content length for 
> dofilter() method in our logs. The JavaScript is not the culprit in this 
> case. The JavaScript sets the AJAX field to success after sending request and 
> thereafter waits for response(which is not received in our case). Our 
> application works fine for lesser than 2 gb fie uploads but fails for greater 
> size files as the request fails to reach the dofilter() method after which 
> the request can be forwarded to the requested method.


So you have an evidence that your Javascript method call returned, but
you have no evidence that browser have actually sent the request nor
that the request has reached Tomcat.

You say "the request fails to reach the dofilter() method" so there is
no evidence that the request was received.

Try debugging
https://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics#Common_Troubleshooting_Scenario

Try submitting the file with a simple , without AJAX.


See this thread from archives of this list (August 2012):
http://tomcat.markmail.org/message/32t2glp3nbo2npag


> Struts: 2.3.24

The current version is 2.3.24.1 (released 3 months ago)
http://struts.apache.org/announce.html#a20150924


Best regards,
Konstantin Kolinko

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Kiran Badi]

Did you exclude your upload servlet from struts.xml ? By default struts
intercepts all multi part requests and this messes a lot specially when you
have hybrid framework when few modules are plain j2ee and few are struts 2
or Spring MVc in the same app.

Are you upload less than 2gb file ?

On Monday, January 18, 2016, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Rahul,
>
> On 1/17/16 11:28 PM, Rahul Singh wrote:
> > Code flow is attached, forgot to attach in trailing mail.
> >
> > --
> - --
> >
> >
> *From:* Rahul Singh <rksing...@hotmail.com <javascript:;>>
> > *Sent:* Monday, January 18, 2016 8:39 AM *To:* Tomcat Users List
> > *Subject:* Re: File size >= 2GB not uploaded in application
> > [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]
> >
> > Hello Christopher, thanks for your prompt response !!
> >
> >> Why didn't you come to the Tomcat community first?
> > Sorry for the delay, we wanted to make sure about the component
> > causing the problem.
> >
> >
> >>> I don't have a test-case in front of me, but I'm fairly
> >>> confident that Tomcat allows file uploads of greater than 2GiB.
> >>> I suspect the problem
> > is another component.
> >>> Are you using Servlet 3.0-based file upload, or are you
> >>> allowing Struts to handle the file-upload for you? If you use
> >>> Servlet-3.0 file-upload, then you'll have code that deals with
> >>> Multipart classes and configuration in web.xml. If you are
> >>> using Struts's file-upload, then you'll mostly just be calling
> >>> getFile or getInputStream or however Struts 2 does things (I
> >>> can't remember how it all works off the top of my head).
> >
> >
> > In our case the filter class implements the javax.servlet.flter
> > and imports javax.servlet.* The Filter class mentioned in the
> > previous threads is the first one as declared in the web.xml
> > (followed by other struts filters). All (url) requests are mapped
> > to this filter. So this is where our file upload request goes. It
> > is only in greater than 2 gb file upload request that the
> > dofilter() fails to get any request. So we feel servlet 3.0 being
> > used in our case the Filter is not being able to handle greater
> > than 2 gb requests.
> >
> >
> >>> The point is, if you are using Struts, then Tomcat will not
> >>> touch the request and Struts is handling the whole thing. If
> >>> Struts is the problem, you'll need to talk to the Struts
> >>> team[1].
> >
> >>> If you are using Servlet-3.0 file-upload, then Struts is just a
> >>> red herring and this is the right place to get your issue
> >>> solved.
> >
> > As mentioned above Servlet 3.0 is being used. So request the
> > tomcat community to please look into our issue.
> >
> >>> So far, you have posted some configuration for Struts and some
> >>> JSP tablib-filled code, plus some Java code for a Filter. You
> >>> didn't say where the Filter was in the filter chain (before or
> >>> after Struts filter). You also mentioned that the form is
> >>> actually posted using XMLHttpRequest and not through a standard
> >>> form, but you didn't explain what component is doing that or
> >>> how it actually works.
> >
> >>> There isn't enough information here to make any sense of the
> >>> situation. Can you please address all of the questions I've
> >>> posed above and maybe we can then help you?
> >
> >
> > <<>>> We need to model the following code to be told:
> > jsp submit of the form How the .js submit it further in
> > XmlHttpRequest How the Filter is declared How the web.xml is
> > declared
> >
> >
> >> Are you sure the request is even made to the server in these
> >> cases?What if the Javascript upload component is failing before
> >> it even starts?
> >
> > Yes the request is made in these cases. We have compared the
> > scenario for greater than 2gb and lesser size file uploads and
> > drawn the following inference from it.We have checked the request
> > and content length for dofilter() method in our logs. The
> > JavaScript is not the culprit in this case. The JavaScript sets the
> > AJAX field to success after sending request and thereafter waits
> > for response(which is not rec

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Code flow is attached, forgot to attach in trailing mail.



From: Rahul Singh <rksing...@hotmail.com>
Sent: Monday, January 18, 2016 8:39 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Hello Christopher,
thanks for your prompt response !!

> Why didn't you come to the Tomcat community first?
Sorry for the delay, we wanted to make sure about the component causing the 
problem.


>>I don't have a test-case in front of me, but I'm fairly confident that
>>Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.
>>Are you using Servlet 3.0-based file upload, or are you allowing
>>Struts to handle the file-upload for you? If you use Servlet-3.0
>>file-upload, then you'll have code that deals with Multipart classes
>>and configuration in web.xml. If you are using Struts's file-upload,
>>then you'll mostly just be calling getFile or getInputStream or
>>however Struts 2 does things (I can't remember how it all works off
>>the top of my head).


In our case the filter class implements the javax.servlet.flter and imports 
javax.servlet.*
The Filter class mentioned in the previous threads is the first one as declared 
in the web.xml (followed by other struts filters).
 All (url) requests are mapped to this filter. So this is where our file upload 
request goes. It is only in greater than 2 gb file upload request that the 
dofilter() fails to get any request.
So we feel servlet 3.0 being used in our case the Filter is not being able to 
handle greater than 2 gb requests.


>>The point is, if you are using Struts, then Tomcat will not touch the
>>request and Struts is handling the whole thing. If Struts is the
>>problem, you'll need to talk to the Struts team[1].

>>If you are using Servlet-3.0 file-upload, then Struts is just a red
>>herring and this is the right place to get your issue solved.

As mentioned above Servlet 3.0 is being used. So request the tomcat community 
to please look into our issue.

>>So far, you have posted some configuration for Struts and some JSP
>>tablib-filled code, plus some Java code for a Filter. You didn't say
>>where the Filter was in the filter chain (before or after Struts
>>filter). You also mentioned that the form is actually posted using
>>XMLHttpRequest and not through a standard form, but you didn't explain
>>what component is doing that or how it actually works.

>>There isn't enough information here to make any sense of the
>>situation. Can you please address all of the questions I've posed
>>above and maybe we can then help you?


<<>>> We need to model the following code to be told:
 jsp submit of the form
How the .js submit it further in XmlHttpRequest
How the Filter is declared
How the web.xml is declared


>Are you sure the request is even made to the server in these cases?What if the 
>Javascript upload component is failing before it even starts?

Yes the request is made in these cases. We have compared the scenario for 
greater than 2gb and lesser size file uploads and drawn the following inference 
from it.We have checked the request and content length for dofilter() method in 
our logs. The JavaScript is not the culprit in this case. The JavaScript sets 
the AJAX field to success after sending request and thereafter waits for 
response(which is not received in our case). Our application works fine for 
lesser than 2 gb fie uploads but fails for greater size files as the request 
fails to reach the dofilter() method after which the request can be forwarded 
to the requested method.



Regards,
Rahul


From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Saturday, January 16, 2016 9:33 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/15/16 1:02 AM, Rahul Singh wrote:
> Thanks for your guidelines, we have big hope from Apache Tomcat
> Team to solve this problem as this is show stopper for our
> application, we have also raise this question on various forum like
> stack overflow and other, but no relevant reply till now.

Why didn't you come to the Tomcat community first?

> Hope you understand my situation,
>
> please refer the below stackoverflow reference for more detail
> about this issue.
>
> http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-
[http://cdn.sstatic.net/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded]<http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any->

doFilter() fails to get any request for the file upload > 
2gb<http://stacko

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Christopher,
thanks for your prompt response !!

> Why didn't you come to the Tomcat community first?
Sorry for the delay, we wanted to make sure about the component causing the 
problem.


>>I don't have a test-case in front of me, but I'm fairly confident that
>>Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.
>>Are you using Servlet 3.0-based file upload, or are you allowing
>>Struts to handle the file-upload for you? If you use Servlet-3.0
>>file-upload, then you'll have code that deals with Multipart classes
>>and configuration in web.xml. If you are using Struts's file-upload,
>>then you'll mostly just be calling getFile or getInputStream or
>>however Struts 2 does things (I can't remember how it all works off
>>the top of my head).


In our case the filter class implements the javax.servlet.flter and imports 
javax.servlet.* 
The Filter class mentioned in the previous threads is the first one as declared 
in the web.xml (followed by other struts filters).
 All (url) requests are mapped to this filter. So this is where our file upload 
request goes. It is only in greater than 2 gb file upload request that the 
dofilter() fails to get any request.
So we feel servlet 3.0 being used in our case the Filter is not being able to 
handle greater than 2 gb requests.


>>The point is, if you are using Struts, then Tomcat will not touch the
>>request and Struts is handling the whole thing. If Struts is the
>>problem, you'll need to talk to the Struts team[1].

>>If you are using Servlet-3.0 file-upload, then Struts is just a red
>>herring and this is the right place to get your issue solved.

As mentioned above Servlet 3.0 is being used. So request the tomcat community 
to please look into our issue.

>>So far, you have posted some configuration for Struts and some JSP
>>tablib-filled code, plus some Java code for a Filter. You didn't say
>>where the Filter was in the filter chain (before or after Struts
>>filter). You also mentioned that the form is actually posted using
>>XMLHttpRequest and not through a standard form, but you didn't explain
>>what component is doing that or how it actually works.

>>There isn't enough information here to make any sense of the
>>situation. Can you please address all of the questions I've posed
>>above and maybe we can then help you?


<<>>> We need to model the following code to be told: 
 jsp submit of the form
How the .js submit it further in XmlHttpRequest
How the Filter is declared 
How the web.xml is declared


>Are you sure the request is even made to the server in these cases?What if the 
>Javascript upload component is failing before it even starts?

Yes the request is made in these cases. We have compared the scenario for 
greater than 2gb and lesser size file uploads and drawn the following inference 
from it.We have checked the request and content length for dofilter() method in 
our logs. The JavaScript is not the culprit in this case. The JavaScript sets 
the AJAX field to success after sending request and thereafter waits for 
response(which is not received in our case). Our application works fine for 
lesser than 2 gb fie uploads but fails for greater size files as the request 
fails to reach the dofilter() method after which the request can be forwarded 
to the requested method.



Regards,
Rahul 


From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Saturday, January 16, 2016 9:33 AM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/15/16 1:02 AM, Rahul Singh wrote:
> Thanks for your guidelines, we have big hope from Apache Tomcat
> Team to solve this problem as this is show stopper for our
> application, we have also raise this question on various forum like
> stack overflow and other, but no relevant reply till now.

Why didn't you come to the Tomcat community first?

> Hope you understand my situation,
>
> please refer the below stackoverflow reference for more detail
> about this issue.
>
> http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-
request-for-the-file-upload-2gb?noredirect=1#comment57315528_34783438
>
>
>
for more information:
>
> -No error are printed in tomcat logs. - how to configure "call
> HttpServletRequest.getHeader("Content-Length") as a String and
> parse it yourself."

I don't have a test-case in front of my, but I'm fairly confident that
Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.

Are you using Servlet 3.0-based file upload, or are you allowing
Struts to handle the file-upload for you?

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[David kerber]

On 1/15/2016 1:02 AM, Rahul Singh wrote:

Dear Christopher,

Thanks for your guidelines, we have big hope from Apache Tomcat Team to solve 
this problem as this is show stopper for our application, we have also raise 
this question on various forum like stack overflow and other,but no relevant 
reply till now.

Hope you understand my situation,

please refer the below stackoverflow reference for more detail about this issue.

http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-request-for-the-file-upload-2gb?noredirect=1#comment57315528_34783438


for more information:

  -No error are printed in tomcat logs.
- how to configure "call HttpServletRequest.getHeader("Content-Length") as a String 
and parse it yourself."


This is straight forward java programming that you should be able to 
handle yourself.  It could be done in one line, though I personally 
wouldn't do it that way.




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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rahul,

On 1/15/16 1:02 AM, Rahul Singh wrote:
> Thanks for your guidelines, we have big hope from Apache Tomcat
> Team to solve this problem as this is show stopper for our
> application, we have also raise this question on various forum like
> stack overflow and other, but no relevant reply till now.

Why didn't you come to the Tomcat community first?

> Hope you understand my situation,
> 
> please refer the below stackoverflow reference for more detail
> about this issue.
> 
> http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-
request-for-the-file-upload-2gb?noredirect=1#comment57315528_34783438
>
>
> 
for more information:
> 
> -No error are printed in tomcat logs. - how to configure "call 
> HttpServletRequest.getHeader("Content-Length") as a String and
> parse it yourself."

I don't have a test-case in front of my, but I'm fairly confident that
Tomcat allows file uploads of greater than 2GiB. I suspect the problem
is another component.

Are you using Servlet 3.0-based file upload, or are you allowing
Struts to handle the file-upload for you? If you use Servlet-3.0
file-upload, then you'll have code that deals with Multipart classes
and configuration in web.xml. If you are using Struts's file-upload,
then you'll mostly just be calling getFile or getInputStream or
however Struts 2 does things (I can't remember how it all works off
the top of my head).

The point is, if you are using Struts, then Tomcat will not touch the
request and Struts is handling the whole thing. If Struts is the
problem, you'll need to talk to the Struts team[1].

If you are using Servlet-3.0 file-upload, then Struts is just a red
herring and this is the right place to get your issue solved.

So far, you have posted some configuration for Struts and some JSP
tablib-filled code, plus some Java code for a Filter. You didn't say
where the Filter was in the filter chain (before or after Struts
filter).  You also mentioned that the form is actually posted using
XMLHttpRequest and not through a standard form, but you didn't explain
what component is doing that or how it actually works.

There isn't enough information here to make any sense of the
situation. Can you please address all of the questions I've posed
above and maybe we can then help you?

Are you sure the request is even made to the server in these cases?
What if the Javascript upload component is failing before it even starts
?

- -chris

[1] http://struts.apache.org/mail.html

>  From: Christopher Schultz 
> <ch...@christopherschultz.net> Sent: Thursday, January 14, 2016
> 8:43 PM To: Tomcat Users List Subject: Re: File size >= 2GB not
> uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK
> 1.7.79]
> 
> André,
> 
> On 1/14/16 5:02 AM, André Warnier (tomcat) wrote:
>> I have not followed this thread in details, but did you check
>> this :
>> 
>> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attri
butes
>>
>>
>> 
- --> maxPostSize
> 
> +1
> 
>> The maximum size in bytes of the POST which will be handled by
>> the container FORM URL parameter parsing. The limit can be
>> disabled by setting this attribute to a value less than zero. If
>> not specified, this attribute is set to 2097152 (2 megabytes).
>> Note that the FailedRequestFilter can be used to reject requests
>> that exceed this limit.
>> 
>> Note: the size above might relate to the *encoded* size of the 
>> file, as it is transmitted over the WWW (possibly encoded as
>> Base64 e.g.), which may mean that an original 1 MB file
>> translates to more than 1 MB bytes while being uploaded.
>> 
>> Note also : maybe "Struts" is setting this to some other default 
>> value..
>> 
>> Another question : did you check the Tomcat logs ?
> 
> IIRC, Tomcat doesn't log anything in these cases. You have to use 
> the FailedRequestFilter to detect and report the condition. I 
> wouldn't use that Filter in productio, but it would be good as a 
> simple test to see if this is the error that is occurring.
> 
> When Tomcat refuses to allow a file upload that it too large, it 
> simply does not parse the parameters, but the request continues to 
> process as usual (but the servlet doesn't end up getting any of
> the parameters). I'm surprised that Struts isn't getting the
> request in these cases.
> 
> -chris
> 
> -
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> ---

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Christopher ,
Thanks for your input,



>ServletRequest.getContentLength is declared to return an int value (32-bit):

>* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
>* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
>* 2147483648 > 2147483647

>Therefore, request.getContentLength cannot be used to fetch
>content-lengths over 2GiB - 1byte.

Yes above is already investigated, BTW thanks .

 You have to use
>ServletRequest.getContentLengthLong (new in servlet 3.1)

for this we have to upgrade tomcat 8, currently we are using tomcat 7.0.54.

> or call
>HttpServletRequest.getHeader("Content-Length") as a String and parse it
>yourself.

OK, but where we need to do this, in init() method or in doFilter() method, but 
FYI, the request(upload file >2GB) is not reached to doFilter().


Apart from above thread we want to share more information so that tomcat team 
help us to get out from this issue.

For my struts project the doFilter() fails to get any request from the file 
upload form in cases the size of the file is greater than 2gb. 
Below is the code fragment:

Filter is as follows:

public void doFilter(ServletRequest req, ServletResponse res, FilterChain 
chain) throws IOException, ServletException
{   
HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) res;
HttpSession session = request.getSession(false);
request.setCharacterEncoding("UTF-8");

/*
do the other business work example request response monitoring and 
logging
*/

 chain.doFilter(request, response);  

}

jsp is :



For my jsp the form is submitted as a XMLHttpRequest via the underlying 
javascipt. 
Now when I upload a a file (lesser than 2gb) ,in my dofilter() method I have 
checked the uri and request length for the request.
They are as expected via the action called in the jsp form and the file size.
The file upload works fine in this case. But in case where the file size is 
greater than 2gb ,
in my doFilter() method no request is available for the file upload action 
called by the form submit(for file size greater than 2 gb). 
Thus the upload does not proceed further in such cases.

I am using servlet 3.0. 
What do I need to do to support larger than 2 gb file uploads, so that the 
request reaches the doFilter() method?




From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, January 13, 2016 8:11 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Rahul,

On 1/12/16 10:56 PM, Rahul Singh wrote:
> Hi,
>
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
>
> Not successful :
>
> Request Never finishes, we have trace the HttpServlet request object
> and request.getContentLength return 0 in case when file size is >=2GB,
>
> No exception thrown, as well as when file size is less than 2GB, then
> request.getContentLength return the correct value of file size in
> byte.

ServletRequest.getContentLength is declared to return an int value (32-bit):

* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
* 2147483648 > 2147483647

Therefore, request.getContentLength cannot be used to fetch
content-lengths over 2GiB - 1byte. You have to use
ServletRequest.getContentLengthLong (new in servlet 3.1) or call
HttpServletRequest.getHeader("Content-Length") as a String and parse it
yourself.

-chris

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

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[tomcat]

Hi.

I have not followed this thread in details, but did you check this :

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes
--> maxPostSize  

The maximum size in bytes of the POST which will be handled by the container FORM URL 
parameter parsing. The limit can be disabled by setting this attribute to a value less 
than zero. If not specified, this attribute is set to 2097152 (2 megabytes). Note that the 
FailedRequestFilter can be used to reject requests that exceed this limit.


Note: the size above might relate to the *encoded* size of the file, as it is transmitted 
over the WWW (possibly encoded as Base64 e.g.), which may mean that an original 1 MB file 
translates to more than 1 MB bytes while being uploaded.


Note also : maybe "Struts" is setting this to some other default value..

Another question : did you check the Tomcat logs ?


On 14.01.2016 10:52, Rahul Singh wrote:

Hello Christopher ,
Thanks for your input,




ServletRequest.getContentLength is declared to return an int value (32-bit):



* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
* 2147483648 > 2147483647



Therefore, request.getContentLength cannot be used to fetch
content-lengths over 2GiB - 1byte.


Yes above is already investigated, BTW thanks .

  You have to use

ServletRequest.getContentLengthLong (new in servlet 3.1)


for this we have to upgrade tomcat 8, currently we are using tomcat 7.0.54.


or call
HttpServletRequest.getHeader("Content-Length") as a String and parse it
yourself.


OK, but where we need to do this, in init() method or in doFilter() method, but 
FYI, the request(upload file >2GB) is not reached to doFilter().


Apart from above thread we want to share more information so that tomcat team 
help us to get out from this issue.

For my struts project the doFilter() fails to get any request from the file 
upload form in cases the size of the file is greater than 2gb.
Below is the code fragment:

Filter is as follows:

public void doFilter(ServletRequest req, ServletResponse res, FilterChain 
chain) throws IOException, ServletException
{
 HttpServletRequest request = (HttpServletRequest) req;
 HttpServletResponse response = (HttpServletResponse) res;
HttpSession session = request.getSession(false);
 request.setCharacterEncoding("UTF-8");

/*
do the other business work example request response monitoring and 
logging
*/

 chain.doFilter(request, response);

}

jsp is :



For my jsp the form is submitted as a XMLHttpRequest via the underlying 
javascipt.
Now when I upload a a file (lesser than 2gb) ,in my dofilter() method I have 
checked the uri and request length for the request.
They are as expected via the action called in the jsp form and the file size.
The file upload works fine in this case. But in case where the file size is 
greater than 2gb ,
in my doFilter() method no request is available for the file upload action 
called by the form submit(for file size greater than 2 gb).
Thus the upload does not proceed further in such cases.

I am using servlet 3.0.
What do I need to do to support larger than 2 gb file uploads, so that the 
request reaches the doFilter() method?




From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, January 13, 2016 8:11 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

Rahul,

On 1/12/16 10:56 PM, Rahul Singh wrote:

Hi,


Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


Not successful :

Request Never finishes, we have trace the HttpServlet request object
and request.getContentLength return 0 in case when file size is >=2GB,

No exception thrown, as well as when file size is less than 2GB, then
request.getContentLength return the correct value of file size in
byte.


ServletRequest.getContentLength is declared to return an int value (32-bit):

* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
* 2147483648 > 2147483647

Therefore, request.getContentLength cannot be used to fetch
content-lengths over 2GiB - 1byte. You have to use
ServletRequest.getContentLengthLong (new in servlet 3.1) or call
HttpServletRequest.getHeader("Content-Length") as a String and parse it
yourself.

-chris

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

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




---

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Dear Christopher,

Thanks for your guidelines, we have big hope from Apache Tomcat Team to solve 
this problem as this is show stopper for our application, we have also raise 
this question on various forum like stack overflow and other,but no relevant 
reply till now.

Hope you understand my situation,

please refer the below stackoverflow reference for more detail about this 
issue. 

http://stackoverflow.com/questions/34783438/dofilter-fails-to-get-any-request-for-the-file-upload-2gb?noredirect=1#comment57315528_34783438


for more information:

 -No error are printed in tomcat logs.
- how to configure "call HttpServletRequest.getHeader("Content-Length") as a 
String and parse it yourself."







From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, January 14, 2016 8:43 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

André,

On 1/14/16 5:02 AM, André Warnier (tomcat) wrote:
> I have not followed this thread in details, but did you check this :
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes
> --> maxPostSize

+1

> The maximum size in bytes of the POST which will be handled by the
> container FORM URL parameter parsing. The limit can be disabled by
> setting this attribute to a value less than zero. If not specified, this
> attribute is set to 2097152 (2 megabytes). Note that the
> FailedRequestFilter can be used to reject requests that exceed this limit.
>
> Note: the size above might relate to the *encoded* size of the file, as
> it is transmitted over the WWW (possibly encoded as Base64 e.g.), which
> may mean that an original 1 MB file translates to more than 1 MB bytes
> while being uploaded.
>
> Note also : maybe "Struts" is setting this to some other default value..
>
> Another question : did you check the Tomcat logs ?

IIRC, Tomcat doesn't log anything in these cases. You have to use the
FailedRequestFilter to detect and report the condition. I wouldn't use
that Filter in productio, but it would be good as a simple test to see
if this is the error that is occurring.

When Tomcat refuses to allow a file upload that it too large, it simply
does not parse the parameters, but the request continues to process as
usual (but the servlet doesn't end up getting any of the parameters).
I'm surprised that Struts isn't getting the request in these cases.

-chris

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

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

André,

On 1/14/16 5:02 AM, André Warnier (tomcat) wrote:
> I have not followed this thread in details, but did you check this :
> 
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes
> --> maxPostSize   

+1

> The maximum size in bytes of the POST which will be handled by the
> container FORM URL parameter parsing. The limit can be disabled by
> setting this attribute to a value less than zero. If not specified, this
> attribute is set to 2097152 (2 megabytes). Note that the
> FailedRequestFilter can be used to reject requests that exceed this limit.
> 
> Note: the size above might relate to the *encoded* size of the file, as
> it is transmitted over the WWW (possibly encoded as Base64 e.g.), which
> may mean that an original 1 MB file translates to more than 1 MB bytes
> while being uploaded.
> 
> Note also : maybe "Struts" is setting this to some other default value..
> 
> Another question : did you check the Tomcat logs ?

IIRC, Tomcat doesn't log anything in these cases. You have to use the
FailedRequestFilter to detect and report the condition. I wouldn't use
that Filter in productio, but it would be good as a simple test to see
if this is the error that is occurring.

When Tomcat refuses to allow a file upload that it too large, it simply
does not parse the parameters, but the request continues to process as
usual (but the servlet doesn't end up getting any of the parameters).
I'm surprised that Struts isn't getting the request in these cases.

-chris

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi André Warnier,

its 64 bit (OS and JVM)


From: André Warnier (tomcat) <a...@ice-sa.com>
Sent: Wednesday, January 13, 2016 2:17 PM
To: users@tomcat.apache.org
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

maybe a stupid question nowadays, but : is the platform on which you are 
running this
32-bit, or 64-bit ? (OS and JVM)

On 13.01.2016 04:56, Rahul Singh wrote:
> Hi,
>
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
>
> Not successful :
>
> Request Never finishes, we have trace the HttpServlet request object and 
> request.getContentLength return 0 in case when file size is >=2GB,
>
> No exception thrown, as well as when file size is less than 2GB, then 
> request.getContentLength return the correct value of file size in byte.
>
>
> Regards,
> Rahul Kumar Singh
> 
> From: David kerber <dcker...@verizon.net>
> Sent: Tuesday, January 12, 2016 6:07 PM
> To: Tomcat Users List
> Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
> Struts: 2.3.24 JAVA: openJDK 1.7.79]
>
> On 1/12/2016 12:01 AM, Rahul Singh wrote:
>>
>> Hello Apache Tomcat team,
>>
>> Sending again with some corrections,
>>
>> File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
>> 1.7.79) is not successful for greater than 2 gb. After previous discussion 
>> here on previous thread, I migrated my application to struts 2.3.24 as the 
>> only possible solution in form of jakarta-stream parser for large size 
>> uploads (greater than 2gb).
>> But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
>> greater than 2 gb still not supported. I want to use jakarta-streams for 
>> this purpose.Following is the code
>> snippet:
>>
>>
>> In struts.xml:
>> 
>>
>> 
>> 
>>
>> In JSP:
>> ===
>>
>> > namespace="xyz"   validateFields="false" method="post"
>> enctype="multipart/form-data">
>>
>>
>> Alongwith with configuring server.xml with maxPostSize element and 
>> mutipart-config in web.xml But still the file upload request for greater 
>> than 2 gb not successful.
>
> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
> never starts?  Never finishes?
>
>
> -
> 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
>


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

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[tomcat]

maybe a stupid question nowadays, but : is the platform on which you are running this 
32-bit, or 64-bit ? (OS and JVM)


On 13.01.2016 04:56, Rahul Singh wrote:

Hi,


Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


Not successful :

Request Never finishes, we have trace the HttpServlet request object and 
request.getContentLength return 0 in case when file size is >=2GB,

No exception thrown, as well as when file size is less than 2GB, then 
request.getContentLength return the correct value of file size in byte.


Regards,
Rahul Kumar Singh

From: David kerber <dcker...@verizon.net>
Sent: Tuesday, January 12, 2016 6:07 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

On 1/12/2016 12:01 AM, Rahul Singh wrote:


Hello Apache Tomcat team,

Sending again with some corrections,

File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous discussion here 
on previous thread, I migrated my application to struts 2.3.24 as the only 
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb still not supported. I want to use jakarta-streams for this 
purpose.Following is the code
snippet:


In struts.xml:





In JSP:
===




Alongwith with configuring server.xml with maxPostSize element and mutipart-config 
in web.xml But still the file upload request for greater than 2 gb not 
successful.


Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


-
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




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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Christopher Schultz]

Rahul,

On 1/12/16 10:56 PM, Rahul Singh wrote:
> Hi,
> 
>> Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>> never starts?  Never finishes?
> 
> Not successful :
> 
> Request Never finishes, we have trace the HttpServlet request object
> and request.getContentLength return 0 in case when file size is >=2GB,
> 
> No exception thrown, as well as when file size is less than 2GB, then
> request.getContentLength return the correct value of file size in
> byte.

ServletRequest.getContentLength is declared to return an int value (32-bit):

* Integer.MAX_VALUE  = 2^31 - 1 = 2147483647
* 2GiB = 2 * 1024 * 1024 * 1024 = 2147483648
* 2147483648 > 2147483647

Therefore, request.getContentLength cannot be used to fetch
content-lengths over 2GiB - 1byte. You have to use
ServletRequest.getContentLengthLong (new in servlet 3.1) or call
HttpServletRequest.getHeader("Content-Length") as a String and parse it
yourself.

-chris

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hi,

>Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
>never starts?  Never finishes?

Not successful :

Request Never finishes, we have trace the HttpServlet request object and 
request.getContentLength return 0 in case when file size is >=2GB,

No exception thrown, as well as when file size is less than 2GB, then 
request.getContentLength return the correct value of file size in byte.


Regards,
Rahul Kumar Singh

From: David kerber <dcker...@verizon.net>
Sent: Tuesday, January 12, 2016 6:07 PM
To: Tomcat Users List
Subject: Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 
Struts: 2.3.24 JAVA: openJDK 1.7.79]

On 1/12/2016 12:01 AM, Rahul Singh wrote:
>
> Hello Apache Tomcat team,
>
> Sending again with some corrections,
>
> File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
> 1.7.79) is not successful for greater than 2 gb. After previous discussion 
> here on previous thread, I migrated my application to struts 2.3.24 as the 
> only possible solution in form of jakarta-stream parser for large size 
> uploads (greater than 2gb).
> But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
> greater than 2 gb still not supported. I want to use jakarta-streams for this 
> purpose.Following is the code
> snippet:
>
>
> In struts.xml:
> 
>
> 
> 
>
> In JSP:
> ===
>
>  namespace="xyz"   validateFields="false" method="post"
> enctype="multipart/form-data">
>
>
> Alongwith with configuring server.xml with maxPostSize element and 
> mutipart-config in web.xml But still the file upload request for greater than 
> 2 gb not successful.

Define "Not successful"?  Exceptions thrown?  File truncated?  Upload
never starts?  Never finishes?


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

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

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[David kerber]

On 1/12/2016 12:01 AM, Rahul Singh wrote:


Hello Apache Tomcat team,

Sending again with some corrections,

File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous discussion here 
on previous thread, I migrated my application to struts 2.3.24 as the only 
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb still not supported. I want to use jakarta-streams for this 
purpose.Following is the code
snippet:


In struts.xml:





In JSP:
===




Alongwith with configuring server.xml with maxPostSize element and mutipart-config 
in web.xml But still the file upload request for greater than 2 gb not 
successful.


Define "Not successful"?  Exceptions thrown?  File truncated?  Upload 
never starts?  Never finishes?



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

File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Apache Tomcat team,


File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous
discussion here on previous thread, I migrated my application to struts 2.3.24 
as the only
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb
still not supported. I want to use jakarta-streams for this purpose.Following 
is the code
snippet:
In struts.xml:constant name="struts.multipart.parser" 
value="jakarta-stream" /constant
name="struts.multipart.maxSize" value="3147483648" /
jsp file:s:form id="uploadData" action="abc_UploadAction" namespace="xyz" 
validateFields="false"
method="post" enctype="multipart/form-data"

Alongwith with configuring server.xml with maxPostSize element and 
mutipart-config in web.xml
But still the file upload request for greater than 2 gb not successful.


Thanks
Rahul

Re: File size >= 2GB not uploaded in application [Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 1.7.79]

[Rahul Singh]

Hello Apache Tomcat team,

Sending again with some corrections,

File upload in my  application(Tomcat 7.0.54 Struts: 2.3.24 JAVA: openJDK 
1.7.79) is not successful for greater than 2 gb. After previous discussion here 
on previous thread, I migrated my application to struts 2.3.24 as the only 
possible solution in form of jakarta-stream parser for large size uploads 
(greater than 2gb).
But after successfully migrating to struts 2.3.24 from 2.1.8, file upload 
greater than 2 gb still not supported. I want to use jakarta-streams for this 
purpose.Following is the code
snippet:


In struts.xml:





In JSP:
===




Alongwith with configuring server.xml with maxPostSize element and 
mutipart-config in web.xml But still the file upload request for greater than 2 
gb not successful.


Thanks
Rahul


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

Exception page after installation of Tomcat 7.0.54

[Rajesh Biswas]

Dear Experts,

I have installed Apache Tomcat 7.0.54, after installation when I
open https://host_name:port_number I am getting below exception

org.apache.jasper.JasperException: java.lang.IllegalStateException: No
Java compiler available

org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:585)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:391)


But I am able to open https://host_name:port_number/manager/html page
and can be able proceed with normal operation.


Would you please suggest.


Rajesh

RE: Tomcat 7.0.54 Slow Unpack and Deploy

[Dale Ogilvie]

Process explorer, select columns, Process I/O, delta total bytes might show the 
story.

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Christopher Schultz wrote:

- -1 CPU
+1 I/O

Re: Tomcat 7.0.54 Slow Unpack and Deploy

[Konstantin Kolinko]

2014-07-16 16:31 GMT+04:00 Daniel Mikusa dmik...@gopivotal.com:
 On Wed, Jul 16, 2014 at 8:00 AM, Brandon M. Wagner bran...@tripletech.net
 wrote:

 I'm having an issue with Tomcat 7.0.54 on a Windows Server 2008 machine
 (8GB of RAM, Dual AMD Opteron 8 core CPUs 2.0Ghz) where the .WAR file is
 taking 45 minutes to an hour to unpack and deploy. I can unpack the same
 .WAR file on my development machine (Windows 7, 16GB of RAM, Intel i7 870
 2.93Ghz) in less than 2 minutes.

 Something troubling I'm noticing on the production machine is that the CPU
 usage will hover at around 13%. I've tried setting affinity and priority,
 but still Tomcat is only using the 13% of the CPU.

 Some more information about the production machine:
 -It is disconnected from internet (only intranet access)
 -It has been rebuilt because of the slow deployment issue (was on
 physical box with server 2003 same specs, now on VMWare instance with 2008)

 Information about the .WAR file:
 - .WAR is about 28MB
 - expands to 260MB


 A couple suggestions...

 1.) While you're waiting for the app to deploy take some thread dumps.  I'd
 take several groups of two or three thread dumps, with 10 - 15 seconds
 between each thread dump and maybe 5 minutes between each group.  This
 should give you an idea as to what happening on the server at various
 points in time.  Look for long running threads, which could indicate a
 problem.  More info here.


 http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F
http://wiki.apache.org/tomcat/HowTo#How_do_I_read_a_Java_thread_dump_.3F


+1

How do you measure the timing?

Do you have antivirus scanner on that machine? (They love to inspect
zip files, and for a big file that may take notable time).

Also,
http://wiki.apache.org/tomcat/HowTo/FasterStartUp

Best regards,
Konstantin Kolinko

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

Tomcat 7.0.54 Slow Unpack and Deploy

[Brandon M. Wagner]

I'm having an issue with Tomcat 7.0.54 on a Windows Server 2008 machine 
(8GB of RAM, Dual AMD Opteron 8 core CPUs 2.0Ghz) where the .WAR file is 
taking 45 minutes to an hour to unpack and deploy. I can unpack the same 
.WAR file on my development machine (Windows 7, 16GB of RAM, Intel i7 
870 2.93Ghz) in less than 2 minutes.


Something troubling I'm noticing on the production machine is that the 
CPU usage will hover at around 13%. I've tried setting affinity and 
priority, but still Tomcat is only using the 13% of the CPU.


Some more information about the production machine:
-It is disconnected from internet (only intranet access)
-It has been rebuilt because of the slow deployment issue (was on 
physical box with server 2003 same specs, now on VMWare instance with 2008)


Information about the .WAR file:
- .WAR is about 28MB
- expands to 260MB

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

Re: Tomcat 7.0.54 Slow Unpack and Deploy

[David kerber]

On 7/16/2014 8:00 AM, Brandon M. Wagner wrote:

I'm having an issue with Tomcat 7.0.54 on a Windows Server 2008 machine
(8GB of RAM, Dual AMD Opteron 8 core CPUs 2.0Ghz) where the .WAR file is
taking 45 minutes to an hour to unpack and deploy. I can unpack the same
.WAR file on my development machine (Windows 7, 16GB of RAM, Intel i7
870 2.93Ghz) in less than 2 minutes.

Something troubling I'm noticing on the production machine is that the
CPU usage will hover at around 13%. I've tried setting affinity and
priority, but still Tomcat is only using the 13% of the CPU.


So it's using all of one core (1/8=12.5%).  I don't think TC will 
multi-thread the deployment, so your CPU speed will be a bigger factor 
than the number of CPUs, and your dev machine has a nearly 50% higher 
clock speed.


What is the difference in your HD speed?  Does your dev machine have a 
much faster HD than the production server?  That could make a big 
difference.


Do some digging to see what resource the production server is limiting 
on; I'm guessing CPU and HD I/O.





Some more information about the production machine:
 -It is disconnected from internet (only intranet access)
 -It has been rebuilt because of the slow deployment issue (was on
physical box with server 2003 same specs, now on VMWare instance with 2008)

Information about the .WAR file:
 - .WAR is about 28MB
 - expands to 260MB

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





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

Re: Tomcat 7.0.54 Slow Unpack and Deploy

[David kerber]

On 7/16/2014 8:00 AM, Brandon M. Wagner wrote:

I'm having an issue with Tomcat 7.0.54 on a Windows Server 2008 machine
(8GB of RAM, Dual AMD Opteron 8 core CPUs 2.0Ghz) where the .WAR file is
taking 45 minutes to an hour to unpack and deploy. I can unpack the same
.WAR file on my development machine (Windows 7, 16GB of RAM, Intel i7
870 2.93Ghz) in less than 2 minutes.

Something troubling I'm noticing on the production machine is that the
CPU usage will hover at around 13%. I've tried setting affinity and
priority, but still Tomcat is only using the 13% of the CPU.

Some more information about the production machine:
 -It is disconnected from internet (only intranet access)
 -It has been rebuilt because of the slow deployment issue (was on
physical box with server 2003 same specs, now on VMWare instance with 2008)


Your production server being Virtual definitely won't help its speed either.




Information about the .WAR file:
 - .WAR is about 28MB
 - expands to 260MB

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





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

Re: Tomcat 7.0.54 Slow Unpack and Deploy

[Daniel Mikusa]

On Wed, Jul 16, 2014 at 8:00 AM, Brandon M. Wagner bran...@tripletech.net
wrote:

 I'm having an issue with Tomcat 7.0.54 on a Windows Server 2008 machine
 (8GB of RAM, Dual AMD Opteron 8 core CPUs 2.0Ghz) where the .WAR file is
 taking 45 minutes to an hour to unpack and deploy. I can unpack the same
 .WAR file on my development machine (Windows 7, 16GB of RAM, Intel i7 870
 2.93Ghz) in less than 2 minutes.

 Something troubling I'm noticing on the production machine is that the CPU
 usage will hover at around 13%. I've tried setting affinity and priority,
 but still Tomcat is only using the 13% of the CPU.

 Some more information about the production machine:
 -It is disconnected from internet (only intranet access)
 -It has been rebuilt because of the slow deployment issue (was on
 physical box with server 2003 same specs, now on VMWare instance with 2008)

 Information about the .WAR file:
 - .WAR is about 28MB
 - expands to 260MB


A couple suggestions...

1.) While you're waiting for the app to deploy take some thread dumps.  I'd
take several groups of two or three thread dumps, with 10 - 15 seconds
between each thread dump and maybe 5 minutes between each group.  This
should give you an idea as to what happening on the server at various
points in time.  Look for long running threads, which could indicate a
problem.  More info here.


http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F
   http://wiki.apache.org/tomcat/HowTo#How_do_I_read_a_Java_thread_dump_.3F

2.) You could deploy an exploded WAR directory instead of your WAR file.
 To do this, you'd just want to extract the files manually and then move
them into the webapps directory on your server.  That would allow you to
separate the actual expansion from the time it takes to deploy and start
your application.

Dan

Re: Tomcat 7.0.54 Slow Unpack and Deploy

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/16/14, 8:10 AM, David kerber wrote:
 On 7/16/2014 8:00 AM, Brandon M. Wagner wrote:
 I'm having an issue with Tomcat 7.0.54 on a Windows Server 2008
 machine (8GB of RAM, Dual AMD Opteron 8 core CPUs 2.0Ghz) where
 the .WAR file is taking 45 minutes to an hour to unpack and
 deploy. I can unpack the same .WAR file on my development machine
 (Windows 7, 16GB of RAM, Intel i7 870 2.93Ghz) in less than 2
 minutes.
 
 Something troubling I'm noticing on the production machine is
 that the CPU usage will hover at around 13%. I've tried setting
 affinity and priority, but still Tomcat is only using the 13% of
 the CPU.
 
 So it's using all of one core (1/8=12.5%).  I don't think TC will 
 multi-thread the deployment, so your CPU speed will be a bigger
 factor than the number of CPUs, and your dev machine has a nearly
 50% higher clock speed.

I'd be surprised if unzipping a WAR file was a CPU-bound process on
today's hardware: the CPU is wy faster than the disk is.

 What is the difference in your HD speed?  Does your dev machine
 have a much faster HD than the production server?  That could make
 a big difference.

+1

Network share?

 Do some digging to see what resource the production server is
 limiting on; I'm guessing CPU and HD I/O.

- -1 CPU
+1 I/O

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

iQIcBAEBCAAGBQJTxnRlAAoJEBzwKT+lPKRYz0cQALmsNjrBCx0Grjo82eGONtn2
tUjWWej0sgMLnxMLcKoHUblxiVbeRsC1W1UG7PF0TYbz1Mxs98N4xzguSVsnEkP9
hYEWv8jMyAoCMJA/GTyQZ4TD5b7x9tBhtCRkkGwDAe0yZdasFZkbvOBmMW3xvXiu
JpTcVVwJd/+5ewgCFAwrPWhmbtnlroDGHFw92Xm0wCutFMeY9MUqSI/jL4oeemiD
QWY8WL+y7D8F76sHymVV3XT1q+biRsrIxC+HaN+3En75EeStOxZ6fjrhkVswYynO
IhPSls+ndOyEVCq0EARkFT5zpVq5DDKf0V7XVcDy/XLGXrk3g82SXi0xPlfHu2g1
fMp4LH6OKTHmG94iV3gHnYfK2cuy5p8tO1g0sj3OMmLIwFDKziv9QxRulQQCfCpY
bvluFH6WMURZ9/Wmwqzln0w/zOMxOzH3biCv/A+FJA2P88mA3G4bFHNuQbGjN4Y4
ygTzk2H4+7zG3aeSvZQra6TptDPWPa+OKKDlx7QosZnxhC0n8Cjm4bvwHz+2cyN7
KhF6l4in5XCUEAOnfKk8j2HoAckNiQQ0INmG1u67IPAXM0y3W359SoxpGQojl5qk
tRH1TUEnKemd+pt/1Swts/8tCuksVX0XAF0FhSXmNvARdpMWiaYrL1mcneRcew0l
rQsyLHDqvA6OoeHK4GNN
=TFO5
-END PGP SIGNATURE-

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

c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 supports

[Jeff Cai]

Hi, 

In tomcat 7.0.54, the variable is not supported.
I changed the source 
apache-tomcat-7.0.54/webapps/examples/jsp/tagplugin/foreach.jsp

c:set var=num value=20 /
c:forEach var=item begin=1 end={$num}
${item}
/c:forEach

Then it reports:

org.apache.jasper.JasperException: Unable to compile class for JSP

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:672)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
root cause

java.lang.NumberFormatException: For input string: {$num}

java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
java.lang.Integer.parseInt(Integer.java:492)
java.lang.Integer.valueOf(Integer.java:582)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:605)

org.apache.jasper.compiler.Generator$GenerateVisitor.convertString(Generator.java:3184)

org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:3001)

org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3106)

org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2276)

org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1768)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435)
org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Generator.generate(Generator.java:3517)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)


I did same tests on Tomcat 7.0.37 and this error did not happen.

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

Re: c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 supports

[Konstantin Kolinko]

2014-06-05 13:50 GMT+04:00 Jeff Cai jeff_...@symantec.com:
 Hi,

 In tomcat 7.0.54, the variable is not supported.
 I changed the source 
 apache-tomcat-7.0.54/webapps/examples/jsp/tagplugin/foreach.jsp

 c:set var=num value=20 /
 c:forEach var=item begin=1 end={$num}
 ${item}
 /c:forEach

 Then it reports:

 org.apache.jasper.JasperException: Unable to compile class for JSP
 
 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:672)
 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
 root cause

 java.lang.NumberFormatException: For input string: {$num}
 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 java.lang.Integer.parseInt(Integer.java:492)
 java.lang.Integer.valueOf(Integer.java:582)
 org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:605)
 
 org.apache.jasper.compiler.Generator$GenerateVisitor.convertString(Generator.java:3184)
 
 org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:3001)
 
 org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3106)
 
 org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2276)
 
 org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1768)
 org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538)
 org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
 org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429)
 org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435)
 org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
 org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
 org.apache.jasper.compiler.Generator.generate(Generator.java:3517)
 org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
 org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
 org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
 org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
 
 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)
 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)


 I did same tests on Tomcat 7.0.37 and this error did not happen.


What are the first lines of your WEB-INF/web.xml file?

My guess is that you are adhering to an old version of specification
there, that does not support EL.

I can also suggest you to configure your Tomcat in strict servlet
compliance mode and see whether it complaints.

http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification

Best regards,
Konstantin Kolinko

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

RE: c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 supports

[Jeff Cai]

Sorry, I made a mistake in defining the variable.

Jeff

-Original Message-
From: Jeff Cai [mailto:jeff_...@symantec.com] 
Sent: Thursday, June 05, 2014 5:51 PM
To: users@tomcat.apache.org
Subject: c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 
supports

Hi, 

In tomcat 7.0.54, the variable is not supported.
I changed the source 
apache-tomcat-7.0.54/webapps/examples/jsp/tagplugin/foreach.jsp

c:set var=num value=20 /
c:forEach var=item begin=1 end={$num}
${item}
/c:forEach

Then it reports:

org.apache.jasper.JasperException: Unable to compile class for JSP

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:672)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
root cause

java.lang.NumberFormatException: For input string: {$num}

java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
java.lang.Integer.parseInt(Integer.java:492)
java.lang.Integer.valueOf(Integer.java:582)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:605)

org.apache.jasper.compiler.Generator$GenerateVisitor.convertString(Generator.java:3184)

org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:3001)

org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3106)

org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2276)

org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1768)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435)
org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Generator.generate(Generator.java:3517)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)

org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)


I did same tests on Tomcat 7.0.37 and this error did not happen.

Jeff
-
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

Tomcat 7.0.54 - Session invalidate broken in some apps

[David Rees]

I've found that certain applications will no longer invalidate
sessions after upgrading from 7.0.53 to 7.0.54.

It seems to require clustering to be set up in Tomcat. If it's not set
up, session invalidation works fine.

So far, I can only trigger it in a webapp that uses Tapestry Spring Security.

I see a few changes in the changelog related to session invalidate and
clustering, could one of these changes be responsible?

Anyone else see the same issue?

-Dave

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

Re: Tomcat 7.0.54 - Session invalidate broken in some apps

[Konstantin Kolinko]

2014-05-29 11:58 GMT+04:00 David Rees dree...@gmail.com:
 I've found that certain applications will no longer invalidate
 sessions after upgrading from 7.0.53 to 7.0.54.

 It seems to require clustering to be set up in Tomcat. If it's not set
 up, session invalidation works fine.

 So far, I can only trigger it in a webapp that uses Tapestry Spring Security.

 I see a few changes in the changelog related to session invalidate and
 clustering, could one of these changes be responsible?


What are the symptoms?

Is there anything unusual in the log files?

Is a single web application affected, or it spans several applications
(via Single Sign On)?

You may consider debugging.
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

You may consider simplifying you configuration to build a simple
reproduce scenario for a bug report.

 Anyone else see the same issue?


Best regards,
Konstantin Kolinko

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

Re: Tomcat 7.0.54 - Session invalidate broken in some apps

[David Rees]

On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko
knst.koli...@gmail.com wrote:
 2014-05-29 11:58 GMT+04:00 David Rees dree...@gmail.com:
 I've found that certain applications will no longer invalidate
 sessions after upgrading from 7.0.53 to 7.0.54.

 It seems to require clustering to be set up in Tomcat. If it's not set
 up, session invalidation works fine.

 So far, I can only trigger it in a webapp that uses Tapestry Spring Security.

 I see a few changes in the changelog related to session invalidate and
 clustering, could one of these changes be responsible?

 What are the symptoms?

The symptoms are that you expect the current session to be invalidated
and issued a new session on subsequent requests, but instead the
session remains valid and all data in the session remains.

 Is there anything unusual in the log files?

Nothing in the logs as far as I can tell.

 Is a single web application affected, or it spans several applications
 (via Single Sign On)?

Only a single web application affected.

 You may consider debugging.
 http://wiki.apache.org/tomcat/FAQ/Developing#Debugging

 You may consider simplifying you configuration to build a simple
 reproduce scenario for a bug report.

Yes, those are my next steps, just haven't gotten that far yet and
wanted to see if anyone else was seeing anything similar.

Thanks

Dave

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

Re: Tomcat 7.0.54 - Session invalidate broken in some apps

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 5/29/14, 3:12 PM, David Rees wrote:
 On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko 
 knst.koli...@gmail.com wrote:
 2014-05-29 11:58 GMT+04:00 David Rees dree...@gmail.com:
 I've found that certain applications will no longer invalidate 
 sessions after upgrading from 7.0.53 to 7.0.54.
 
 It seems to require clustering to be set up in Tomcat. If it's
 not set up, session invalidation works fine.
 
 So far, I can only trigger it in a webapp that uses Tapestry
 Spring Security.
 
 I see a few changes in the changelog related to session
 invalidate and clustering, could one of these changes be
 responsible?
 
 What are the symptoms?
 
 The symptoms are that you expect the current session to be
 invalidated and issued a new session on subsequent requests, but
 instead the session remains valid and all data in the session
 remains.

Do you mean that you have a web application that does this:

  session.invalidate();
  session = request.getSession(true);

... and the old session is in fact not invalidated?

 Is there anything unusual in the log files?
 
 Nothing in the logs as far as I can tell.
 
 Is a single web application affected, or it spans several
 applications (via Single Sign On)?
 
 Only a single web application affected.
 
 You may consider debugging. 
 http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
 
 You may consider simplifying you configuration to build a simple 
 reproduce scenario for a bug report.
 
 Yes, those are my next steps, just haven't gotten that far yet and 
 wanted to see if anyone else was seeing anything similar.

Please demonstrate that the session is in fact not validated. Given
your description, if this is really happening, it should be trivial to
create a test-case.

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

iQIcBAEBCAAGBQJTh4eHAAoJEBzwKT+lPKRYaggP/1+ImY4rFsro1aA0Rc6LeTWE
SV0wm/Ic7Elux15nr9wWFHDPi1k6RhpLp1TcI9RS8dpw0sXMjMjg2iMjZQn2+ETe
7gr3nI8vnzz6lYcnPmI9ckC0nOXB5J/1UcdE7M8P/tmKmYhZBXX1PdvIx5mwkowH
YojmXzmtt8GfFAfuux0xv5RgcfpXbz9VmjSmfZxD6zlIuoa0pxkYHgNGKsFatMYd
vK8yDUsBd+yOHRFMev6iO1XrePNRa8xOtwfKYeDQQ/kQNB1pqW0tQ2jJ1+NSMbVc
WWM1SgS44NFatrQgUqX0uMKM2q8Jx57CnSlXGrk0yIiGMcOp+egXt1i8XTSdY92f
gxHbwfkmz7U/dGztnjQxSAjerNFGFS8puaCHW6Ot5EThT9MQDytYkhwcFAqK3Zmg
R1zqPj+MYQb8IBDQ1HaV57d0xhLFErriCPShsb9dH9Hubo77DOPUc3TkdLJJ9f4C
eq+dyCO/Rt4JQEu5myWJsQAczZoZoFQYm3QOhaTNMxq/KzQ5ZDcfwmIpF4J8wWtM
0SFoqTYVQAFCYUHBNDgro+F3TpA55dwhTofOk3h4DcmDPAXucq7aq2cs5+FIiQS3
7MHDkDPPQr4gI+mGVPIZRGrUbpQ54+EhNUYga722knkaxDzkP9UxW5kix63bEDck
Pdbe3wXdaaO3ZRms0kGf
=/iQW
-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.0.54 - Session invalidate broken in some apps

[David Rees]

On Thu, May 29, 2014 at 12:16 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Do you mean that you have a web application that does this:

   session.invalidate();
   session = request.getSession(true);

 ... and the old session is in fact not invalidated?

Yes. Specifics to make this happen seem to be:

TC 7.0.54 in a cluster, Tapestry 5.2.6 + Tapestry Spring Security.

7.0.53 is OK.
7.0.54 standalone is OK
Tapestry App without spring security is OK.
Plain old servlet apps work fine.

 Please demonstrate that the session is in fact not validated. Given
 your description, if this is really happening, it should be trivial to
 create a test-case.

Yes, just haven't had the time yet.

-Dave

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

Re: Tomcat 7.0.54 - Session invalidate broken in some apps

[David Rees]

On Thu, May 29, 2014 at 12:39 PM, David Rees dree...@gmail.com wrote:

 Yes. Specifics to make this happen seem to be:

 TC 7.0.54 in a cluster, Tapestry 5.2.6 + Tapestry Spring Security.

OK, I was wrong, no Tapestry or Spring Security is required, just a
couple JSPs are required to reproduce. Key is that clustering needs to
be enabled.

Drop these two JSP files into your 7.0.54 cluster enabled web app.

/** session.jsp **/

%@page session=true%
html
body
table
trtdSession creation time:/tdtd%= session.getCreationTime()
%/td/tr
trtdSession last accessed:/tdtd%=
session.getLastAccessedTime() %/td/tr
trtdCurrent time:/tdtd%= System.currentTimeMillis() %/td/tr
trtdIs Session Id from URL?:/tdtd%=
request.isRequestedSessionIdFromURL() %/td/tr
trtda href=session.jspReload Page/a/tdtda
href=invalidate.jspInvalidate/a/td/tr
/table
/body
/html

/** invalidate.jsp **/
%
request.getSession().invalidate();
response.sendRedirect(session.jsp);
%

Make sure
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster/
is added to the Host of the webapp you dropped the files above into.

Clicking on Reload Page will show the same creation time. On a 7.0.53
if you click on Invalidate, you will get a new creation time. On
7.0.54, you do not.

I'll open a ticket with these details, too.

-Dave

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