Re: Upload big file for data

[Kyohei Nakamura]

Hi Edwin

First, you don't provide the information about your apps.
If you want to get a better answer, you should provide your Tomcat version,
configuration and apps infomation.

If you use the multipart/form-data in order to uploading a file, you can
use the following settings.

* web.xml

  
x
  


Or you can use the following annotation.

  @MultipartConfig(maxFileSize=x)

In addition, when the allowCasualMultipartParsing attribute of the Context
element set to true (the default is false), will be able to parse
multipart/form-data request bodies.
At the time, the max file size is used the value of the maxPostSize
attribute of the Connector element.


If you use the POST data, you can see the maxPostSize attribute description
of the Connector docs.

2016-01-12 0:25 GMT+09:00 Edwin Quijada :

> Hi!
> I am newbie using Tomcat and I have a problem uploadind a Big file. I
> wanna upload a big file CSV, 140 mb, but when this begins doesnt happen
> anything . There is any setting to change for allowing to upload this file.
> This file has record will be procesed into my app.
>
>
> Thks in Advance
>

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

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: 
jsp file:

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: Parameter handling on forward

[Mark Olsson]

Adding = to a parameter does cause it to be available to the destination
servlet, but that doesn't seem like a particularly good solution.  A
parameter without a value is technically a keyless value, not the other way
around.  But I'll stick to the servlet terminology of calling them
parameter names and values since request.getParameterNames and
getParameterMap both return them as "Names" and not a value without a
name.  Parameters without a value (keyless value) are widely used and
within spec without having to add the =.

I wrote a couple of servlets and have been able to narrow down the problem
to take form POST data out of the equation, but not been able to find a
solution yet.  I'm even more convinced that
getRequestDispatcher().forward() or the receiving servlet are borking the
parameters.

This works:
Directly access /page1?a=1&b&c=3&d
The request arrives at the servlet with all 4 parameters, a and c have
values, b and d don't but are in the parameter names list.

This doesn't work:
request.getRequestDispatcher("/page1?a=1&b&c=3&d").forward(request,
response);
The request arrives at the servlet with only the parameters a and c, not b
and d.  All 4 parameters are in the query string, but b and d are not in
the parameter names list or map.

Seems to me that if the exact same servlet can accept parameters without a
value on a direct request, but fails on only some parameters when it's from
a request dispatcher that something is wrong where the parameters are
gathered the second time, or somewhere before they are made available to
the destination.

On Mon, Jan 11, 2016 at 3:41 PM, Andreas Junius  wrote:

> Did you try:
>
> "/page2?foo=&bar=123"
>
> Normally parameters come as key/value pairs, separated by an equal sign.
>
>
>
> On 12/01/16 09:21, Mark Olsson wrote:
>
>> I'm getting unexpected parameter handling with a
>> request.getRequestDispatcher().forward().  Not sure if this is a bug or
>> I'm
>> using gRD.f wrong, but here's the situation:
>>
>> A POST is made with form data to a servlet (didn't try with a multipart
>> content, just regular) and the servlet decides to redirect to another
>> servlet using request.getRequestDispatcher().forward(), but adds
>> parameters
>> on the new address.  Address parameters with a value "asdf=123" *are* sent
>> to the new servlet but parameters without a value *aren't*.
>>
>> Example:
>> 1. POST made to page1 with parameters input1="asdf" and button1 (no
>> value).
>> 2. The servlet handling page1 redirects to page2 and adds 2 parameters:
>>
>> request.getRequestDispatcher("/page2?foo&bar=123").forward(request,response).
>> 3. page2 gets the original parameters input1="asdf", button1, and new
>> bar="123" but not foo.  foo is in the browser address and is in the
>> request
>> query string, but it's not one of the parameters sent along with the
>> request object.  Neither request.getParameterNames() nor
>> request.getParameter() will find "foo".  It also doesn't appear in the
>> list
>> of parameters in Netbeans' server monitor.
>> 4. Changing the order of the parameters (/page2?bar=123&foo) doesn't fix
>> it, but adding a value to foo does (/page2?foo=x&bar=123).
>>
>> So what's up with valueless parameters on a servlet forward?
>>
>> Tomcat: 8.0.26
>> Java: 1.8.0_60 Oracle
>> OS: Win7 and Linux 3.14.20-20.44.amzn1.x86_64
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Parameter handling on forward

[Andreas Junius]

Did you try:

"/page2?foo=&bar=123"

Normally parameters come as key/value pairs, separated by an equal sign.


On 12/01/16 09:21, Mark Olsson wrote:

I'm getting unexpected parameter handling with a
request.getRequestDispatcher().forward().  Not sure if this is a bug or I'm
using gRD.f wrong, but here's the situation:

A POST is made with form data to a servlet (didn't try with a multipart
content, just regular) and the servlet decides to redirect to another
servlet using request.getRequestDispatcher().forward(), but adds parameters
on the new address.  Address parameters with a value "asdf=123" *are* sent
to the new servlet but parameters without a value *aren't*.

Example:
1. POST made to page1 with parameters input1="asdf" and button1 (no value).
2. The servlet handling page1 redirects to page2 and adds 2 parameters:
request.getRequestDispatcher("/page2?foo&bar=123").forward(request,response).
3. page2 gets the original parameters input1="asdf", button1, and new
bar="123" but not foo.  foo is in the browser address and is in the request
query string, but it's not one of the parameters sent along with the
request object.  Neither request.getParameterNames() nor
request.getParameter() will find "foo".  It also doesn't appear in the list
of parameters in Netbeans' server monitor.
4. Changing the order of the parameters (/page2?bar=123&foo) doesn't fix
it, but adding a value to foo does (/page2?foo=x&bar=123).

So what's up with valueless parameters on a servlet forward?

Tomcat: 8.0.26
Java: 1.8.0_60 Oracle
OS: Win7 and Linux 3.14.20-20.44.amzn1.x86_64



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

Parameter handling on forward

[Mark Olsson]

I'm getting unexpected parameter handling with a
request.getRequestDispatcher().forward().  Not sure if this is a bug or I'm
using gRD.f wrong, but here's the situation:

A POST is made with form data to a servlet (didn't try with a multipart
content, just regular) and the servlet decides to redirect to another
servlet using request.getRequestDispatcher().forward(), but adds parameters
on the new address.  Address parameters with a value "asdf=123" *are* sent
to the new servlet but parameters without a value *aren't*.

Example:
1. POST made to page1 with parameters input1="asdf" and button1 (no value).
2. The servlet handling page1 redirects to page2 and adds 2 parameters:
request.getRequestDispatcher("/page2?foo&bar=123").forward(request,response).
3. page2 gets the original parameters input1="asdf", button1, and new
bar="123" but not foo.  foo is in the browser address and is in the request
query string, but it's not one of the parameters sent along with the
request object.  Neither request.getParameterNames() nor
request.getParameter() will find "foo".  It also doesn't appear in the list
of parameters in Netbeans' server monitor.
4. Changing the order of the parameters (/page2?bar=123&foo) doesn't fix
it, but adding a value to foo does (/page2?foo=x&bar=123).

So what's up with valueless parameters on a servlet forward?

Tomcat: 8.0.26
Java: 1.8.0_60 Oracle
OS: Win7 and Linux 3.14.20-20.44.amzn1.x86_64

First DB Pool connection returns stale data?

[Tieman,Brian]

I¹ve got a REST service that¹s backed by Hibernate calling MYSQL and using
org.apache.tomcat.jdbc.pool.DataSourceFactory for DB connections.  The
connection pool is created with:



It looks like the first record retrieved from the service is being stored
somehow.  I can alter the data retrieved by the first select but I¹ll
occasionally get the initial data back on a subsequent selects.  After
much troubleshooting, it feels like the stale data is returned only when
my select is performed with the same connection (from the pool) as the
first select since the service started.  I don¹t know how to tell for sure
that the initial connection is the one holding onto old data but the old
data is always the first data I¹ve read and it will be returned seemingly
randomly although the data in the underlying database is correct and we
have no caching turned on in hibernate.

My test procedure has been:

1) Start service
2) Read record
3) Change record
4) Read record
5) Repeat 4


If nothing else is hitting the service (no concurrency) I never see stale
data.  It¹s only when other clients are hitting the service that I
randomly get stale data returned.  The stale data is always the first
record read and is only returned when attempting to read that record again.

Has anyone ever seen anything like this?  Ideas on where to troubleshoot?

Thanks in advance for any input!




CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.

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

Re: Tomcat 8.0.30 Session lost

[Olaf Kock]

Well, at least you do a bit of protection instead of just disabling the
session fixation security filter. However, be aware that potentially
many people might come from the same IP address - either because it's a
NATing home router or a big company's proxy server. Especially if you
want to attack someone who's in the same network as yourself, this
IP-based protection is quite useless.

I think I'm seeing the problems, and as long as you know what you're
doing and you accept the unavoidable consequences of this lower grade
protection, everything is fine.

It still sounds funny that the session is not available with the next
requests... Might be worth to try different browsers for their timing on
the receipt of the cookie

Also, as you call HttpServletRequest.login manually, double check that
you're doing this before the response is committed to the client,
specifically before any other (old) session id cookie is already in the
response stream. It sounds weird, but might help you debug further (note
that I'm not looking at tomcat's code. Apologies if I'm not making sense)

Olaf

Am 11.01.2016 um 21:52 schrieb Thomas Scheffler:
>
> I will file two bugs soon describing the issues I had. Hopefully they
> will be fixed.
>
> 1.) if using HttpServetRequest.login(String, String) further request
> in the session are loosing the users Principal.
>
> 2.) After changing sessionId, old sessionIds should still be valid for
> a short period of time of to the same client.
>
> Fixing one of these would cause the bug to disappear.
>
> To prevent session fixation attacks, I use IP address checking so that
> sessions are bound to the same IP address.
>
> Thanks to all the responses. Without you help it would have not been
> possible to get this fixed after two month of searching!
>
> kind regards,
>
> Thomas
>
> -
> 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 8.0.30 Session lost

[Mark Thomas]

On 11/01/2016 20:52, Thomas Scheffler wrote:
> Am 11.01.16 um 12:21 schrieb André Warnier (tomcat):
>> So the solution in your case, is to make sure, in your application
>> logic, that the first unauthenticated request would be totally processed
>> by the server, and the response processed by the client, before the
>> client sends a second request.
>> If you do this, then the second client request /will/ contain the /same/
>> authentication token as the first request, and you will not have this
>> problem.
>>
>> How to achieve this, is left as an exercise for the reader.
> 
> This means changing all browsers to submit only one concurrent request
> if the server is Apache Tomcat? Really?

No, it simply means you have to construct your application in a sane
manner so the client won't issue parallel requests for protected resources.

> 
>changeSessionIdOnAuthentication="false" />
> 
> Found on
> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
> the description how to switch the "feature" off.
> 
> I will file two bugs soon describing the issues I had. Hopefully they
> will be fixed.
> 
> 1.) if using HttpServetRequest.login(String, String) further request in
> the session are loosing the users Principal.
> 
> 2.) After changing sessionId, old sessionIds should still be valid for a
> short period of time of to the same client.

The second request will get closed as INVALID on security grounds. If
the old ID is valid for any period of time it makes a session fixation
attack possible. You might as well disable changing the session ID on
authentication.

For the first the description above isn't clear enough to be sure
exactly what you are asking for. However, based on the second request
and what I have read of this thread I suspect that request will get
closed as INVALID or WONTFIX.

Mark


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

Re: Tomcat 8.0.30 Session lost

[Thomas Scheffler]

Am 11.01.16 um 12:21 schrieb André Warnier (tomcat):

So the solution in your case, is to make sure, in your application
logic, that the first unauthenticated request would be totally processed
by the server, and the response processed by the client, before the
client sends a second request.
If you do this, then the second client request /will/ contain the /same/
authentication token as the first request, and you will not have this
problem.

How to achieve this, is left as an exercise for the reader.


This means changing all browsers to submit only one concurrent request 
if the server is Apache Tomcat? Really?




Found on 
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection 
the description how to switch the "feature" off.


I will file two bugs soon describing the issues I had. Hopefully they 
will be fixed.


1.) if using HttpServetRequest.login(String, String) further request in 
the session are loosing the users Principal.


2.) After changing sessionId, old sessionIds should still be valid for a 
short period of time of to the same client.


Fixing one of these would cause the bug to disappear.

To prevent session fixation attacks, I use IP address checking so that 
sessions are bound to the same IP address.


Thanks to all the responses. Without you help it would have not been 
possible to get this fixed after two month of searching!


kind regards,

Thomas

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

Re: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Gael Abadin]

The server certificate is self signed. Appart from the typical warning we
see no errors when we check it.

His system (windows) clock is synchronized using microsoft's NTP server,
same as mine.

This is really weird because I have already delopoyed the same app and
config in two other systems, appart from mine, without any issues, and his
and mine are basically the same...

2016-01-11 16:51 GMT+01:00 David Balažic :

> Wrong system clock?
>
> What does the client say? (about the server certificate. Is it valid?
> Expired?)
>
> Regards,
> David Balažic
> Software Engineer
> www.comtrade.com
>
> > -Original Message-
> > From: Gael Abadin [mailto:gael.aba...@imatia.com]
> > Sent: 11. January 2016 10:16
> > To: Tomcat Users List
> > Subject: SSL client cert selection dialog not showing up on cloned
> > deployment of tomcat 7 for windows x64
> > Importance: Low
> >
> > A colleague was having trouble setting up client cert auth on this web
> app
> > we are developing. He tried the latest tomcat 6 and 7 win32 installs
> using
> > java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
> > from eclipse, but even though the SSL connector had clientAuth="want"
> > there
> > was no client cert request when establishing the SSL connection.
> >
> > I had a similar problem before because of an expired self-signed server
> > certificate so I sent him my .keystore file with the new cert that I am
> > using and he replaced his with mine. Still a no go.
> >
> > Then I sent him my own tomcat and eclipse tomcat x64 deployment config
> > and
> > we switched his runtime to the same as mine (latest Java 8 x64). Same
> > problem.
> >
> > At this point I don't know what else to try. His setup is exactly the
> same
> > as mine, but I can't get the client auth to work on his.
> >
> > Any ideas?
> >
> >
> >
> > --
> >
> >
> >
> > .
> >
> > Alberto Gael Abadin Martinez
> > Junior Developer
> >
> > [image: IMATIA]
> >
> > www.imatia.com
> >
> > *Tel: *+34 986 342 774 ext 4531
> >
> > *Email: *gael.aba...@imatia.com
> > Edificio CITEXVI
> > Fonte das Abelleiras, s/n - Local 27
> > 36310 Vigo (Pontevedra)
> > España
> >
> > .
> > 
> > 
> >
> > .
> >
> > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> > contener información confidencial, siendo para uso exclusivo del
> > destinatario. Queda prohibida su divulgación copia o distribución a
> > terceros sin la autorización expresa del remitente. Si usted ha recibido
> > este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
> > su borrado. Gracias por su colaboración.
> > This message, and in the case of any file annexed to it, can have
> > confidential information, and it is exclusively for the use of the
> > addressee of the message. It is strictly forbidden to spread a copy or
> > distribute to third parties, without the express order of the sender. If
> > you have received this message mistakenly, we request you to notify to
> the
> > sender, and please be sure to erase it. Thank you for your collaboration.
> >
> > .
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.



.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

RE: SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[David Balažic]

Wrong system clock?

What does the client say? (about the server certificate. Is it valid? Expired?)

Regards,
David Balažic
Software Engineer
www.comtrade.com

> -Original Message-
> From: Gael Abadin [mailto:gael.aba...@imatia.com]
> Sent: 11. January 2016 10:16
> To: Tomcat Users List
> Subject: SSL client cert selection dialog not showing up on cloned
> deployment of tomcat 7 for windows x64
> Importance: Low
> 
> A colleague was having trouble setting up client cert auth on this web app
> we are developing. He tried the latest tomcat 6 and 7 win32 installs using
> java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
> from eclipse, but even though the SSL connector had clientAuth="want"
> there
> was no client cert request when establishing the SSL connection.
> 
> I had a similar problem before because of an expired self-signed server
> certificate so I sent him my .keystore file with the new cert that I am
> using and he replaced his with mine. Still a no go.
> 
> Then I sent him my own tomcat and eclipse tomcat x64 deployment config
> and
> we switched his runtime to the same as mine (latest Java 8 x64). Same
> problem.
> 
> At this point I don't know what else to try. His setup is exactly the same
> as mine, but I can't get the client auth to work on his.
> 
> Any ideas?
> 
> 
> 
> --
> 
> 
> 
> .
> 
> Alberto Gael Abadin Martinez
> Junior Developer
> 
> [image: IMATIA]
> 
> www.imatia.com
> 
> *Tel: *+34 986 342 774 ext 4531
> 
> *Email: *gael.aba...@imatia.com
> Edificio CITEXVI
> Fonte das Abelleiras, s/n - Local 27
> 36310 Vigo (Pontevedra)
> España
> 
> .
> 
> 
> 
> .
> 
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
> contener información confidencial, siendo para uso exclusivo del
> destinatario. Queda prohibida su divulgación copia o distribución a
> terceros sin la autorización expresa del remitente. Si usted ha recibido
> este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
> su borrado. Gracias por su colaboración.
> This message, and in the case of any file annexed to it, can have
> confidential information, and it is exclusively for the use of the
> addressee of the message. It is strictly forbidden to spread a copy or
> distribute to third parties, without the express order of the sender. If
> you have received this message mistakenly, we request you to notify to the
> sender, and please be sure to erase it. Thank you for your collaboration.
> 
> .

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

Upload big file for data

[Edwin Quijada]

Hi!
I am newbie using Tomcat and I have a problem uploadind a Big file. I wanna 
upload a big file CSV, 140 mb, but when this begins doesnt happen anything . 
There is any setting to change for allowing to upload this file. This file has 
record will be procesed into my app.


Thks in Advance

Loadbalancing and failover not working.

[Weare Borg]

Hello Friends,

1 month back I had asked  a question about loadbalancing and failover using
apache2 and Tomcat. I was on holidays after that and unfortunately I cannot
find the email anymore. I created a new configuration by remembering what
Christopher had told me. Now I have no holidays, so will finalize this
problem. Kindly help me out with what I am doing wrong.

I am trying to create load-balancing and fail-over using mod_jk and
attached behind are 2 tomcat instances which I am connecting with AJP.

As of now I am only getting a blank page whenever I try to load the
website.

Apache2 config :

workers.properties :

worker.list=loadbalancer
>  worker.server1.port=8010
>  worker.server1.host=localhost
>  worker.server1.lbfactor=1
>  worker.server1.type=ajp13
>
>
>  worker.server2.port=8011
>  worker.server2.host=localhost
>  worker.server2.type=ajp13
>  worker.server2.lbfactor=1
>
>
>  worker.loadbalancer.type=lb
>  worker.loadbalancer.balance_workers=server1,server2
>
> worker.loadbalancer.sticky_session=true
> worker.myworker.sticky_session_force=True
>
>
apache2.conf / httpd.conf :

> Include sites-enabled/
> LoadModule jk_module modules/mod_jk.soJkWorkersFile 
> /etc/apache2/workers.propertiesJkLogFile   /etc/apache2/mod_jk.logJkMount /* 
> loadbalancer
>
> sites-enabled/000-default : Only contains :

>  JkMountCopy On
>
> First tomcat's server.xml :

>
> 
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/ 
> javascript,application/x-javascript,application/javascript"/> name="Catalina" defaultHost="localhost" jvmRoute="server1">
>   className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
> 
>
>
 2nd Tomcat's server.xml :
>
> 
>compressableMimeType="text/html,text/xml,text/plain,text/css,text/ 
> javascript,application/x-javascript,application/javascript"/>
>   
>  
>   
> 
>
>
With this config, I get only a blank page. Kindly help me out. Again,
apologies for creating a new thread. Thanks a lot. :-)

RE: close_wait in Tomcat 7.0.63

[Prashant Kaujalgi]

Hi Team,

Please let me know if any solution is present. This issue is hampering the 
application up time.
Please let me know if any other details are required.

Best Regards,
Prashant Kaujalgi


-Original Message-
From: Prashant Kaujalgi [mailto:prashant.kauja...@e-nxt.com] 
Sent: Thursday, January 07, 2016 12:28 PM
To: 'Tomcat Users List'
Subject: RE: close_wait in Tomcat 7.0.63

Hi Konstantin,

Thanks for prompt reply. Server.xml contains following resource.



We are having Apache web server (2.2) which sends request to tomcat and when 
tomcat communicates with database it creates close_wait.


Best Regards,
Prashant Kaujalgi



-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Thursday, January 07, 2016 12:15 PM
To: Tomcat Users List
Subject: Re: close_wait in Tomcat 7.0.63

2016-01-07 9:36 GMT+03:00 Prashant Kaujalgi :
> Dear Team,
>
>
>
> First of all, I want to apologies if there is a well known fix to my 
> problem.
>
>
>
> Environment:
>
> OS: Windows server 2008
>
> Tomcat application server: Apache Tomcat 7.0.63
>
> Web server : Apache 2.2
>
> JRE build : jdk1.6.0_23
>
> Connection pooling: Tomcat jdbc connection pooling (Tomcat-jdbc.jar)
>
>
>
> We are having web based application hosted on Tomcat 7. We are facing 
> close_wait issue between tomcat and database
>
> server. After certain time period close_wait count increases and 
> reaches threshold (maxActive="500") after which tomcat was unable to 
> create new thread and we have to restart the service.
>
>
>
> Our observation is that Oracle closes the connection and Tomcat is not 
> able to close the same connection and hence resulting in close_wait
>
>
>
> Below is the sample netstat when CLOSE_WAIT was there. Application 
> server is
> 192.168.15.109 with 219 database server listing on 1527 port.
>
>
>
>   TCP192.168.xx.xx:51588   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51621   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51622   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51623   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51632   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51647   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51648   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51658   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51659   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51691   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51699   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51705   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51706   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51722   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51724   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51725   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51744   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51805   172.16.xx.xx:1527  CLOSE_WAIT  3812
>
>   TCP192.168.xx.xx:51807   172.16.xx.xx:1527  CLOSE_WAIT  3812
>


What is your actual configuration?

Also,
https://bz.apache.org/bugzilla/show_bug.cgi?id=58610#c2

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

Disclaimer & Privilege Notice: This e-Mail may contain proprietary, privileged 
and confidential information and is sent for the intended recipient(s) only. 
If, by an addressing or transmission error, this mail has been misdirected to 
you, you are requested to notify us immediately by return email message and 
delete this mail and its attachments. You are also hereby notified that any 
use, any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and/or publication of this e-mail message, contents 
or its attachment(s) other than by its intended recipient(s) is strictly 
prohibited. Any opinions expressed in this email are those of the individual 
and may not necessarily represent those of e-Nxt Financials Ltd. Before opening 
attachment(s), please scan for viruses.

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

Re: Tomcat 8.0.30 Session lost

[tomcat]

Thomas,

On 11.01.2016 11:30, Thomas Scheffler wrote:

Am 08.01.16 um 17:02 schrieb Christopher Schultz:

Tomcat will change the session identifier when the user authenticates.
If you are creating a session before login, you'll see that the session
id changes when authentication is successful. This is to protect against
session-fixation attacks.


I re-login the user, if tomcat returns "null" on 
HttpRequest.getUserPrincipal(). I noticed
that the sessionId changes. But if I am required to re-login the user on 
parallel
requests, it depends on magic what sessionId is given after all responses are 
delivered to
the browser.

You can see in the logs, that requested sessions are suddenly invalid.

I would not require an other call to the login method if servlet container 
returns a user
once it is authenticated in a session.


Can you explain why the changing session id breaks your application? Are
you storing session ids somewhere and just not updating the session id
list when the session id changes? It should be possibly to listen for
that event and update your session id list. Or maybe there's a better
way to accomplish your goal rather than keeping your own session id
list. (I'm guessing you have a session id list because it would best
explain the behavior you are describing here.)


I do not save the http session id anywhere. The browser saves it in a cookie. 
The cookie
is changing rapidly because the UserPrincipaö is not returned from the request.

Here is something I would prefer:

1. Every request that belongs to a given session returns a non null object when 
calling
getUserPrincipal() after the login() method returns successfully.
2. As you have no control over the net and do not know in which order the 
browser receives
its packets, you can not invalidate a sessionId in a snap. Tomcat has to 
gracefully
invalidate it somehow.

An example:

1. Client logs in
2. Server responds with SID=SID1
3. Client request 2 resources in parallel
4. Server receives first request and handles it, returning SID=SID2
5. Server receives second request (with SID=SID2), which belongs to invalid 
session. Code
is creating a new session than. Server response with SID=SID3
6. Client will use SID3 in future requests which belongs to the new session and 
not the
original session where the user is logged in.



I think that the crux of the issue, is a proper understanding of how the HTTP protocol's 
Basic Authentication works, in its basic form.  Remember, HTTP is old, and at the 
beginning, it did not envision "sessions", nor "simultaneous" requests.  The basic idea was :

- client connects to, and sends one request to the server
- server processes request, and sends response to the client
- server closes connection, and forgets everything about the request just 
processed
Then the next request from a client comes in, etc..
Everything else aftwerward, was built on the basic schema above, as "patches", to allow 
for authentication, "sessions" composed of multiple requests/responses, "persistent 
connections", "cookies" etc..

But the basic logic remains the same to this day.
For Basic authentication, the basic schema is as follows :

1) client establishes a connection to the server
2) client sends a request on that connection, for some server "resource"
3) the server checks if that resource is submitted to some form of 
authentication/authorization/access control.
3.1) if not, the server returns the resource to the client, and the request/response cycle 
is finished.
3.2) if yes (AAA required), the server checks if the request contains some form of 
authentication/authorization.
 3.2.1) if yes (auth provided), the server checks if this authentication/authorization 
matches the requirements for this resource.

  3.2.1.1) if yes, the server returns the resource, and the request/response is 
finished.
  3.2.1.2) if not, the server returns a "forbidden" response, and the request/response is 
finished.
 3.2.2) if not (no auth provided), the server returns a response "authorization required" 
to the client, and the request/response is finished.


In a case like 3.2.2, the client must repeat the request, this time /with/ an 
authentication as required by 3.2 above.


Whenever the server returns a response to the client, it can include a "set cookie" in 
that response.  The next time that the client sends a request to that same server, it will 
then include this cookie, and maybe seeing this cookie will allow the server to respond 
"yes" to the question at 3.2 above.


The above is the basic schema, as included in the HTTP protocol.
There are many other schemes that work, but you have to know that if you differ from the 
schema above, then you are no longer within the strict HTTP protocol, and the 
responsibility of making sure that your alternative scheme works in all circumstances, is 
yours.


In particular, the above scheme will fail in the following scenario :

1) the client sends a request to the server, for a protected resourc

Re: Tomcat 8.0.30 Session lost

[Thomas Scheffler]

Am 08.01.16 um 17:02 schrieb Christopher Schultz:

Tomcat will change the session identifier when the user authenticates.
If you are creating a session before login, you'll see that the session
id changes when authentication is successful. This is to protect against
session-fixation attacks.


I re-login the user, if tomcat returns "null" on 
HttpRequest.getUserPrincipal(). I noticed that the sessionId changes. 
But if I am required to re-login the user on parallel requests, it 
depends on magic what sessionId is given after all responses are 
delivered to the browser.


You can see in the logs, that requested sessions are suddenly invalid.

I would not require an other call to the login method if servlet 
container returns a user once it is authenticated in a session.



Can you explain why the changing session id breaks your application? Are
you storing session ids somewhere and just not updating the session id
list when the session id changes? It should be possibly to listen for
that event and update your session id list. Or maybe there's a better
way to accomplish your goal rather than keeping your own session id
list. (I'm guessing you have a session id list because it would best
explain the behavior you are describing here.)


I do not save the http session id anywhere. The browser saves it in a 
cookie. The cookie is changing rapidly because the UserPrincipaö is not 
returned from the request.


Here is something I would prefer:

1. Every request that belongs to a given session returns a non null 
object when calling getUserPrincipal() after the login() method returns 
successfully.
2. As you have no control over the net and do not know in which order 
the browser receives its packets, you can not invalidate a sessionId in 
a snap. Tomcat has to gracefully invalidate it somehow.


An example:

1. Client logs in
2. Server responds with SID=SID1
3. Client request 2 resources in parallel
4. Server receives first request and handles it, returning SID=SID2
5. Server receives second request (with SID=SID2), which belongs to 
invalid session. Code is creating a new session than. Server response 
with SID=SID3
6. Client will use SID3 in future requests which belongs to the new 
session and not the original session where the user is logged in.


IMHO it would be also secure to lock the sessionId to the IP address 
instead of changing the id but less error-prone. You can even combine it 
and allow old sessionIds only from the original IP address.


If the servlet container would just use the session information for HTML 
pages parallel request are rare. But when serving cachable thumbnails it 
often like checking headers and return 304.


kind regards,

Thomas

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

SSL client cert selection dialog not showing up on cloned deployment of tomcat 7 for windows x64

[Gael Abadin]

A colleague was having trouble setting up client cert auth on this web app
we are developing. He tried the latest tomcat 6 and 7 win32 installs using
java 6 and 7 SDKs. He was able to bring up the app on HTTPS, launching it
from eclipse, but even though the SSL connector had clientAuth="want" there
was no client cert request when establishing the SSL connection.

I had a similar problem before because of an expired self-signed server
certificate so I sent him my .keystore file with the new cert that I am
using and he replaced his with mine. Still a no go.

Then I sent him my own tomcat and eclipse tomcat x64 deployment config and
we switched his runtime to the same as mine (latest Java 8 x64). Same
problem.

At this point I don't know what else to try. His setup is exactly the same
as mine, but I can't get the client auth to work on his.

Any ideas?



-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.



.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

Re: From where org.apache.naming get added to java.naming.factory.url.pkgs in Tomcat 7.x

[Thusitha Thilina Dayaratne]

Sorry for the trouble.
I found that enableNaming() method sets this

Thanks
Thusitha
2016-01-11 14:34 GMT+05:30 Thusitha Thilina Dayaratne <
thusithathil...@gmail.com>:

> Hi,
>
> I checked the tomcat7 source to find out how tomee set the
> *org.apache.naming *to* java.naming.factory.url.pkgs *system property
> which uses for JNDI stuffs. But I couldn't find the place.
>
> Could someone point the location from where tomcat set that property?
>
> Thanks
> Thusitha
> --
>
>


--

From where org.apache.naming get added to java.naming.factory.url.pkgs in Tomcat 7.x

[Thusitha Thilina Dayaratne]

Hi,

I checked the tomcat7 source to find out how tomee set the
*org.apache.naming *to* java.naming.factory.url.pkgs *system property which
uses for JNDI stuffs. But I couldn't find the place.

Could someone point the location from where tomcat set that property?

Thanks
Thusitha
--