yes, most of time is waiting, I use tomcat NIO connector, with async cxf webservice server (exposed as async servlet) and async cxf client, I use no my own threaded-queue regards Jakub ps possibly camel could do it more elegantly and with less programming effort On Tue, Jun 18, 2013 at 5:21 PM, Christopher Schultz < chris@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jakub, > > On 6/18/13 3:27 AM, Ja kub wrote: > > Ravindra, > > > > Thx for idea, I will read about it, but at first glance it looks > > like with 5000 pending servlet requests I will have 5000 threads > > awaiting response from cxf client, with async servlet and async cxf > > webservice server, connected with async cxf client, all 5000 > > pending threads can be served by one thread, > > Sounds like async + your own threaded-queue is the way to go, assuming > that you really have to wait-around a while for CXF responses. > > > I have to deal not only with faults, but also with long running > > webservice client requests - up to two client requests, 20 second > > each > > Most of that time is just sitting there waiting, right? > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRwHrzAAoJEBzwKT+lPKRYqu0P/iMUOAqDZ0sSI2evQhz7xJh/ > tPaOeF6bISOqfCfbyFKesZrDEDoc/wZrdBmzfkT+72M8jKfbY4MBGCtvkol0ffcl > SWEphu5wW2TRxcaoG6r7DWrCtE87AJaofgvd+VtN9lE0fPtdXJqf0s8bnE/+I2TN > hnoyNXfhC/3lMNGG16d6/1Vi16qWV4d+H5Fo9fz3ohunBBHFq6L10OxXRu7alL// > KKpyenMn2KFZeGsokty2dmMr9bNW2PYgHTXrjZCK8DU8iTGtCRRPoZtF2ZJWcchP > qSZxm1ZqFFLsWbRd54ixdmivvk2OEleoDhgjYGRSuPt36vYcfhGP4svuMvcWA+bR > juipkA0kKxZjRQ0kFfjqoowQIL+iLsUeBmfeL8YchxvFkzt0bTskfUnEd60kzTCo > dfGJkBCuPR5qjXwffYHJd3mDlPjL9hd2npcns8KQgad0WJA5rZZdmEl7K2vKpOw7 > fBy4r3gJR2T+g0974+UoqBcTU+wdIebIe6XPF7GweNS6fbCTekTjM1iS/JFj3Qrc > mtGj85i5QEmgTpLRQqZG+N4lY/4Rpvk+i9JsmP4KvQAT1Dkgcs95IAPrettDWqNs > ZKPtZJBeW+tnsi5ZXET4M3fnFoxdCK1+7igrYHjbvs4sXlmWyc1gz9lrTnO/nmHY > 6vaOUf6Nfw6M5EFcG9Or > =UZ+y > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Steve, On 6/18/13 12:58 PM, Steve Nickels wrote: > Christopher Schultz wrote: >>>> Do you think there are ways it could be improved? Better >>>> error checking, etc.? I implemented it as simply as I >>>> possibly could. >>> >>> The biggest problem seems to be that something in Tomcat on >>> Windows is interfering with OpenSSL's normal base address >>> request (0xFB00000). Normally this doesn't matter, but with the >>> FIPS build, if the base address of the library is moved from >>> what it expects, the result is a fingerprint error when FIPS >>> mode is enabled. >> >> This could be a problem on *NIX as well -- any library may be >> re-located by the loader for any reason. > > It's possible this could be a problem on *NIX, but it's my > understanding that this error is pretty specific to Windows. The > documentation for OpenSSL FIPS says that the > FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED error code is a > "Microsoft Windows specific error". Interesting. I'll have to read a bit more about that. >>> I ran the openssl utility on the same system as Tomcat, and >>> Process Explorer shows that its copy of libeay32.dll stays at >>> the correct address. Additionally, I tested the FIPS-compatible >>> libeay32.dll on a different server with Tomcat, and had the >>> same problem. This seems to indicate that the memory address >>> issue is specific to Tomcat, not the server. >> >> Or running within a JVM which has a significant amount of native >> code that gets loaded first, which may cause the loader to >> re-locate the library when it finally gets loaded. >> >> Any interest in trying some Java-based testing using >> libtcnative? > > I'm game, if you let me know what you'd like me to do. : ) All you should have to do is write a small Java program that calls AprLifecycleListener.lifecycleEvent with an event of type BEFORE_INIT_EVENT. You'll of course have to call things like setFIPSMode(true), etc. I wonder if you did that without the rest of Tomcat loaded if anything would change. I would bet that it's more likely that the bulk of the JVM is causing the re-location of the library than anything else. Interesting thread: http://comments.gmane.org/gmane.comp.encryption.openssl.devel/18309 Look at Andy Polyakov's comment from 18 Oct 2010 23:25 where he says: " In order for this to work it is implied that compiler moves relocatable data from .rdata segment. Unix compiler actually do that, but apparently not Windows :-(. " It also looks like OpenSSL has updated their build scripts for Visual Studio, but it's possible that the FIPS version predates that patch. >>> I can't tell from Process Explorer why libeay32.dll is being >>> rebased (I didn't see any other libraries under tomcat7.exe >>> that were obviously taking up the same address space). I think >>> it's going to take someone with more experience with both >>> Windows and Tomcat than >> I >>> to figure that one out. I suppose it might be worthy of a bug >>> report, at least. >> >> That would be good -- bug reports have more visibility than >> mailing list posts, and it's a good place to collect information >> all in one place. > > I submitted bug 55113 for this. > (https://issues.apache.org/bugzilla/show_bug.cgi?id=55113) I saw that, thanks. >> I'm curious: what base address did you use when you changed it? > > The one that worked for me was 0x6FB00000. Did you just choose one randomly? I wonder if you follow the suggestions from the aforementioned thread for re-building everything with the /FIXED switch. That seems to have fixed everyone's issues, but you have to be sure to build everything very carefully or one component can still be relocatable. tcnative of course does not care. >> That's a good point. Could you log that in Bugzilla as well? >> There are (brief) building instructions on >> http://tomcat.apache.org/native-doc/ but they should probably >> also be in the BUILDING file. > > Submitted bug 55114 for this. > (https://issues.apache.org/bugzilla/show_bug.cgi?id=55114) Cool. It's likely to be fixed in a different way (by including both *NIX and Windows building instructions instead of including only the Windows build instructions) but at least you won't have to go to the web site when you have a perfectly good file already downloaded. >>> If there's a good place to put a wiki page about this, let me >>> know, and I can try to add something. >> >> Really anywhere under http://wiki.apache.org/tomcat/FAQ would be >> great. If I were looking for information about this, I'm not sure >> where I'd look first. Perhaps under "Security"? > > If I get a chance, I'll try and add something here. Cool, thanks. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRwJesAAoJEBzwKT+lPKRY8FgP/3R7y0R0xTHEkbnQmyYfSPXP 3ClMJFJQPh+Co/FE+uw3su/c1+0/ajf3t5Fvv3XIEKKbgMxu8wOLSM9oVzQ6ITEP QeHqy9+MPCAezcxZnysg2q/O5Bcuc+S/xEYpg3PH7qo/CGYVSPj25MvZxUM+murS L86kosspQLmq6mxgWqsHZVZ7AL5o6eO/cI4ThntGdBTRT4ErM4Lc6fuC2n/h//Js VzHa49OywAnpM8/Pyfh18ewlVtvJ+BEETs+LnsAk3Ifz9WnhlvgDlIjAj8S2fPUL ukrPET3zhVVWMtKc2iHBKAaI97U89Wk1M3bGyEoO6YIyVUVQyt7Ajy05J0Bze3Dz 2ncbdtKExZONqR/xe9QP9fBX5R2tyh9qSBDG31hRpy3FbA3YLelpm8/Rlnm2Ou/x AZ3u1DIfmJjkEBt/QpQcGu4nlyxHz9LmGH0kzzQYUgU1XAB/p3wWBjYpQXQ/C/gh H+Qc4QgaZEJ6GAvfFgrvGENwRI+AqSqeZBWK199fNsJORmmusyDlg8xOpvSDwcmE OP/02qm4CPtTinH2oJC6Vt/c3rPGNWWmnZ/q07hD+KDURcD7K2O/gN7jOdb642A/ fvt+eY5mvVa51isLsGzM2hRyHK/WXCHxq12ipqxLqN+u096VWJMRkUAJHYDFazrw O2Bu+Wz78O04p5XZiZYL =qMI+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
> >> Do you think there are ways it could be improved? Better error > >> checking, etc.? I implemented it as simply as I possibly could. > > > > The biggest problem seems to be that something in Tomcat on Windows > > is interfering with OpenSSL's normal base address request (0xFB00000). > > Normally this doesn't matter, but with the FIPS build, if the base > > address of the library is moved from what it expects, the result is a > > fingerprint error when FIPS mode is enabled. > > This could be a problem on *NIX as well -- any library may be re-located by > the loader for any reason. It's possible this could be a problem on *NIX, but it's my understanding that this error is pretty specific to Windows. The documentation for OpenSSL FIPS says that the FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED error code is a "Microsoft Windows specific error". > > I ran the openssl utility on the same system as Tomcat, and Process > > Explorer shows that its copy of libeay32.dll stays at the correct > > address. Additionally, I tested the FIPS-compatible libeay32.dll on a > > different server with Tomcat, and had the same problem. This seems to > > indicate that the memory address issue is specific to Tomcat, not the > > server. > > Or running within a JVM which has a significant amount of native code that > gets loaded first, which may cause the loader to re-locate the library when it > finally gets loaded. > > Any interest in trying some Java-based testing using libtcnative? I'm game, if you let me know what you'd like me to do. : ) > > I can't tell from Process Explorer why libeay32.dll is being rebased > > (I didn't see any other libraries under tomcat7.exe that were > > obviously taking up the same address space). I think it's going to > > take someone with more experience with both Windows and Tomcat than > I > > to figure that one out. I suppose it might be worthy of a bug report, > > at least. > > That would be good -- bug reports have more visibility than mailing list posts, > and it's a good place to collect information all in one place. I submitted bug 55113 for this. (https://issues.apache.org/bugzilla/show_bug.cgi?id=55113) > I'm curious: what base address did you use when you changed it? The one that worked for me was 0x6FB00000. > > If the fix for the memory rebasing issue ends up being that OpenSSL > > needs to be configured with a different base address, that would be > > good to include in the build documentation for tcnative. > > The file \jni\native\srclib\BUILDING would be a good place for such a > > note. But, if the interfering Tomcat piece were to be found and > > resolved, you wouldn't need it. > > I suspect this is an OS-related thing that Tomcat can't really affect. > Note that (other than tcnative and the win32 service-launcher), Tomcat > doesn't have any native code at all, so it can't really affect this kind of stuff. > Tomcat just issues a System.loadLibrary() call and lets the JVM and OS take > over. > > >>> With my test application, the original base address was not being > >>> changed by the OS, according to process explorer, which is why it > >>> worked with the original build. > >>> > >>> Thanks for your help! > >> > >> No problem. If there were any other gotchas you found when building > >> tcnative/FIPS/win32 could you let us know? Actually, creating a Wiki > >> page is easy to do and you could help others who are trying to do the > >> same thing. > > > > One minor issue I found when building tcnative on Windows was that > > the BUILDING file in the \jni\native directory in > > tomcat-native-1.1.27-win32-src.zip appears to contain UNIX build > > instructions. This probably isn't appropriate, since the zip file is > > specific to win32. > > That's a good point. Could you log that in Bugzilla as well? There are > (brief) building instructions on http://tomcat.apache.org/native-doc/ > but they should probably also be in the BUILDING file. Submitted bug 55114 for this. (https://issues.apache.org/bugzilla/show_bug.cgi?id=55114) > > If there's a good place to put a wiki page about this, let me know, > > and I can try to add something. > > Really anywhere under http://wiki.apache.org/tomcat/FAQ would be great. > If I were looking for information about this, I'm not sure where I'd look first. > Perhaps under "Security"? If I get a chance, I'll try and add something here. --Steve Nickels Ipswitch, Inc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 William, On 6/17/13 11:10 PM, William Kang wrote: > I got the following error by submitting the code from RMI client to > RMI server: java.rmi.ServerException: RemoteException occurred in > server thread; nested exception is: java.rmi.UnmarshalException: > error unmarshalling arguments; nested exception is: > java.lang.ClassNotFoundException: mypackage.SomeClass I assume mypackage.SomeClass is one of your internal classes? Typically, you need to provide the .class files for the objects you expect to receive via RMI on the client as well as the server. If you want to to dynamic .class file downloading from the server, you'll need to do something like this: http://stackoverflow.com/questions/4762430/rmi-question-where-do-clients-get-a-definition-for-remote-classes-that-have-no - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRwHwxAAoJEBzwKT+lPKRY2dcQAJdjP+7A9PjTjzNNdxFisFbE H5r48HwEe5Nn87FNqDAsPAQTnERdAJfU089n6QuYh88uXuru/+Kqd9fXfLhq4Ver 0RClHNzUp41BsnJGQOO0yTeqn+FoZIH4qbKJbnhQjDYZG0fO/bsknnbUUi0II+SB 7EpXPdEtw8dhGlgkoQNmS7Q4lM3pnFOfm6Tuao/qwuIAZwIcYrAlCxzZWWAHvpBJ K9nYAY632AKBd7XXpPvCeYahyoKCDRy1UxDqHITh1/qN9UgLIakVzSmWNgV58wae CYutgDHXCeTDwU6P+cEoK4JZ/nE+FMgIQAc2SQOts6Y+xuflR16+/Ijh+Zejgbc1 x+3bdVVWPp6kb59of/yYmpHrhvsr1dAvjRXl486VU/WzYOs7B46SXIPeYtp6jljP Le9P7JjDdzknXBfImB7QWkQmGBZ5tBplGCTAr8qdAQ7w7/Eflsc3MXWqyrsDlqZe wlRBF+thftWN14YGvvg++Zu0S0I+hKyxZu4cDy3CsogmGBfurMIyjodtb7x8Ikqf wQjSwFXpmn8GwaWuUr1i7kJ/blyipmCEh8hbWtqQRjFcpteFpTkx98NkJwGjrTXe TVQVrEjV/UDcqdsqNZ90mzqrIJ8bTIpn1c7RM9XCz0KrMAZ6I81CtjtqFd+faAh+ V4zpLRTRn4nLHB7aUUUE =nk0/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jakub, On 6/18/13 3:27 AM, Ja kub wrote: > Ravindra, > > Thx for idea, I will read about it, but at first glance it looks > like with 5000 pending servlet requests I will have 5000 threads > awaiting response from cxf client, with async servlet and async cxf > webservice server, connected with async cxf client, all 5000 > pending threads can be served by one thread, Sounds like async + your own threaded-queue is the way to go, assuming that you really have to wait-around a while for CXF responses. > I have to deal not only with faults, but also with long running > webservice client requests - up to two client requests, 20 second > each Most of that time is just sitting there waiting, right? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRwHrzAAoJEBzwKT+lPKRYqu0P/iMUOAqDZ0sSI2evQhz7xJh/ tPaOeF6bISOqfCfbyFKesZrDEDoc/wZrdBmzfkT+72M8jKfbY4MBGCtvkol0ffcl SWEphu5wW2TRxcaoG6r7DWrCtE87AJaofgvd+VtN9lE0fPtdXJqf0s8bnE/+I2TN hnoyNXfhC/3lMNGG16d6/1Vi16qWV4d+H5Fo9fz3ohunBBHFq6L10OxXRu7alL// KKpyenMn2KFZeGsokty2dmMr9bNW2PYgHTXrjZCK8DU8iTGtCRRPoZtF2ZJWcchP qSZxm1ZqFFLsWbRd54ixdmivvk2OEleoDhgjYGRSuPt36vYcfhGP4svuMvcWA+bR juipkA0kKxZjRQ0kFfjqoowQIL+iLsUeBmfeL8YchxvFkzt0bTskfUnEd60kzTCo dfGJkBCuPR5qjXwffYHJd3mDlPjL9hd2npcns8KQgad0WJA5rZZdmEl7K2vKpOw7 fBy4r3gJR2T+g0974+UoqBcTU+wdIebIe6XPF7GweNS6fbCTekTjM1iS/JFj3Qrc mtGj85i5QEmgTpLRQqZG+N4lY/4Rpvk+i9JsmP4KvQAT1Dkgcs95IAPrettDWqNs ZKPtZJBeW+tnsi5ZXET4M3fnFoxdCK1+7igrYHjbvs4sXlmWyc1gz9lrTnO/nmHY 6vaOUf6Nfw6M5EFcG9Or =UZ+y -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
On 18/06/2013 04:10, William Kang wrote:
> I DID NOT set up the security manager in the code, I assume that Tomcat
> will use its own.
> //if (System.getSecurityManager() == null) {
> // System.setSecurityManager(new SecurityManager());
> //}
Only if you start Tomcat with a security manager.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
On 17/06/2013 23:08, Jeff_Shanholtz@McAfee.com wrote: > We have precompiled tags which were compiled under 5.5.35 and don't > work under 7.0.34. From my investigation, it appears it's due to an > interface change in JspSourceDependent. The return type of > getDependants() changed. For us the solution isn't as simple as > recompiling for two reasons: we have shipping products which plug > into our tomcat based platform and some such products target multiple > versions of our platform, some of which are 5.5 based and some are > 7.0 based. > > Is this a bug? No. > Shouldn't there be backward compatibility for > precompiled tags? No. While we don't break compatibility very often, there is no guarantee of compatibility for pre-compiled tags (or JSPs) even between point releases let alone between releases two major versions apart. Pre-compilation is only supported when performed against the release that that pre-compiled artefacts will be running on. > Is there anything that can be done to get such > existing tags working? > I'm looking for any guidance on how to move > forward in addressing this issue. 5.5.x is no longer supported so that short answer is move all your products to 7.0.x. Over 12 months notice was given for 5.5.x end-of-life so there really is no excuse for not having moved to 7.0.x already. Other options that come to mind: - don't pre-compile the tag files - pre-compile as part of the install procedure rather than at build time - patch Tomcat 5 (that will break any existing pre-compiled tags) - re-write your tag files as tags Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
Ravindra, Thx for idea, I will read about it, but at first glance it looks like with 5000 pending servlet requests I will have 5000 threads awaiting response from cxf client, with async servlet and async cxf webservice server, connected with async cxf client, all 5000 pending threads can be served by one thread, I have to deal not only with faults, but also with long running webservice client requests - up to two client requests, 20 second each regards Jakub ps possibly apache camel can do with it, I have to check in spare time. On Mon, Jun 17, 2013 at 5:51 AM, Vanga Palli, Ravindra Kumar < ravindra.vangapalli@hp.com> wrote: > Ja kub, > > Looks like you are re-inventing wheel here. All you are looking for is a > fault tolerance system, you should consider exploring hystrix - latency > and fault tolerance for distributed systems library. > > https://github.com/Netflix/Hystrix > > -Ravi > > ________________________________________ > From: Ja kub [jjakub83@gmail.com] > Sent: Thursday, June 13, 2013 1:11 AM > To: Tomcat Users List > Subject: Re: http request (no only session) replication in cluster > > Christopher > Thx for response, I will inform guys from business about what You have > written, and let them consider it > > Regards > Jakub > > > On Wed, Jun 12, 2013 at 4:10 PM, Christopher Schultz < > chris@christopherschultz.net> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Jakob, > > > > On 6/11/13 5:04 PM, Ja kub wrote: > > > requirement is system should be possible to process 160 req/sec > > > (200 is better to multiply) and system is kind of failover proxy > > > itself > > > > > > there are 2 backing webservices, each can answer max 20s, it there > > > is timeout on first, I must call the second, if there is timeout on > > > second I send soap fault to client, so usually it shouldn't be more > > > than 20s per req, guys say that normally it is 7-10 > > > seconds/request, but in worst case it is 2*20s*160 requests/s ~= > > > 6400 pending requests (and according to deal we must fulfill worst > > > case) > > > > If you have 2 member nodes and one of them starts to slow down, then > > you'll see pretty much all requests re-tried on the second node, which > > will slow down that one. I think you'll end up seeing a storm of > > requests bouncing back and forth. > > > > Worse, the initial request will continue processing on the 1st node, > > ignorant of the fact that the lb has given up and tried the other > > node. It's just going to fall apart from there. > > > > Honestly, this should be able to be handled at your lb -- can't you > > set a time-out there? > > > > > even if there are so many requests they are pending on sockets, I > > > try to do it with NIO, asynchronous servlets and async cxf - both > > > async cxf webservice is exposed by me, and I also call backing ws > > > with async cxf I think even one tomcat on one server should be able > > > to serve such 6400 pending requests with 160req/s, apart from proxy > > > there are also 4-6 inserts into database (cli req, resp; 1st ws > > > call, resp; 2nd ws call, resp > > > > > > how do You assess such architecture/attitude ? do You expect > > > problems with async exposed webservice based on async servlet and > > > NIO, and async cxf ws client ? afaik cxf use thread locals, are > > > they all right with tomcat async servlets ? (I don't define > > > threadlocals by myself, only cxf possibly does) > > > > It's not a socket-resource issue, it's a raw work-load issue: you have > > a large amount of load and it looks like you can't handle it very > > well. I would recommend more nodes, first, and then seriously consider > > whether re-trying on a second node is appropriate if the first node > > takes too long. > > > > What you should probably do is actually profile your code to find out > > what is taking so long. Using tricks like ThreadLocals can shed > > microseconds off of a request, not whole seconds. > > > > You might want to consider whether you can do less work during a > > request -- perhaps split a single transaction into more than one. Or, > > just acknowledge that sometimes a transaction can take 10-20 seconds > > (or 50?) and manage the clients' expectations. > > > > You also need to find out where your bottleneck is: RDBMSs, slow > > disks, slow network links, etc. can all be much more significant than > > things like software stack and exact implementation of your code. If > > you are missing an index on a relational table, transactions that > > should take a second or two can take tens of seconds. > > > > Start there: profile your application, find out what is slow, and fix > > that. Don't try to work-around the problem with surprising > > transactional re-tries, because they likely won't work the way you > > hoped. Hey, once you fix your performance problem, perhaps you won't > > need additional hardware. Also, your users will be very happy to see a > > speed improvement. > > > > - -chris > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > > Comment: GPGTools - http://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQIcBAEBCAAGBQJRuIFyAAoJEBzwKT+lPKRYr+4QAL7UCQvZ/CBIueIqhFDLkZ57 > > v0uWcuukEtT8/8dNUBW2SGSE4OwDyH41Nsx7ZVo4W+lTnzduVbjXSvU4lXNDiY19 > > 9MgpwuxZWlUxHAgOQ5NODIFwrHQK2GYMe8+Qo8OBVf6lOhVdB4PS/7XM7lrsnWBn > > rpojl4rPm7+esciZPB1q15+PxCbgh4uGsI4KCXyZiW/gz/dLC2v8u6QiYfqoXgov > > iutYtII+7f1E6I+Ag3LjmQwrzY7pRpHrotcJ4aCpyOs9EHTavKf3mapwY2HiOP+t > > G9qwGuq5tUJhkBzF5Vdvqf+lCbdJHkQtLW3Z4vL4/XTK7SVSvjipFhsttZF4TII6 > > 6QVQmjCJZRYdPDegzB+NVaCxPkdZLLdwHNFFfsZGabdTQDkAKOEXQiYjBqJ9n5nX > > WRHvYLQtyGEj1e+0zqwCihRHie2TbfwdggtCoVaOF+8Zpguv3K9VRHwvFA/miA1i > > JkYCfxKjyF/RoCyB4wZqCi5VsJjztQpq6uDQiUG0CACY1491sB35M+Vkqm3jqRbh > > 0HXs1ckqZsw+2Y013kpCVs0eipOst5GD6XqXr6LTT/fQwEYWa3uVTk3/h2xDd9BT > > DlTZrs1CNhqMBjNqUDUFkiiempf9kFkQhrao50CAilix95/VhdWkDjFcFSKKQ0/J > > EkcONNIioMTN7cWzKNHf > > =miI6 > > -----END PGP SIGNATURE----- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > > For additional commands, e-mail: users-help@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > >
Hi,
I posted a question on stackoverflow but got no answer, can anybody help me
here?
I am having some difficulties with RMI and Tomcat. This is the big picture
of this project I am working on: the RMI client is called by a Java servlet
that runs in Tomcat, the servlet accept user input and pass the parameters
to the RMI client. Then the RMI client then calls the RMI server to run the
heavy compuation part. The problem is that although everything works fine
without hosting the RMI client in the Tomcat server, it doesn't run once I
put it in Tomcat.
Here are some configurations:
I DID NOT set up the security manager in the code, I assume that Tomcat
will use its own.
//if (System.getSecurityManager() == null) {
// System.setSecurityManager(new SecurityManager());
//}
I also set the permission as following:
> $CATALINA_HOME/conf/catalina.policy
grant codeBase "file:${catalina.home}/webapps/MyAPP/WEB-INF/classes/-"
{
permission java.security.AllPermission "", ""; };
grant codeBase "file:${catalina.home}/webapps/MyAPP/WEB-INF/lib/-" {
permission java.security.AllPermission "", "";
};
grant codeBase
"file:${catalina.home}/webapps/MyAPP/WEB-INF/lib/some-common-3.0.jar" {
permission java.io.FilePermission "*", "read, write";
};
Other than these two configurations, I didn't set any
java.rmi.server.codebase or java.security.policy.
I got the following error by submitting the code from RMI client to RMI
server:
java.rmi.ServerException: RemoteException occurred in server thread;
nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException: mypackage.SomeClass
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:334)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:178)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:132)
at com.sun.proxy.$Proxy19.executeTask(Unknown Source)
at
cluster.server.centralservice.CentralManagementServer.submitJob(CentralManagementServer.java:232)
at cluster.server.centralservice.JobSubmitter.runJob(JobSubmitter.java:226)
at cluster.server.centralservice.JobSubmitter.doPost(JobSubmitter.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments;
nested exception is:
java.lang.ClassNotFoundException: mypackage.SomeClass
I have been stuck here for a few days. Most examples I searched online is
outdated and do not cover the RMI with Tomcat set up.
How can I set "java.rmi.server.codebase" in Tomcat 7 or how RMI server can
find the codebase? Everything works fine before puting in Tomcat. Can
anybody help?
The post is listed here:
http://stackoverflow.com/questions/17114804/running-rmi-client-in-tomcat-7-got-classnotfoundexception
Many thanks.
William
Hi Chris,
First, my apologies. Much of the terminology is
unfamiliar to me here. I hope that I've managed to fully answer your
questions.
The "server calls" are all rmi calls on java-based servers
on the same machine. There are no separate threads directly in the .jsp
pages.
The userToken has a few variables (userID, userName, etc) and a
bunch of rmi interface methods. It doesn't directly use a tomcat
request,response, etc. Another way of putting it is that all of these
methods could be called equally well from the command line. Here's a
typical method:
public UserToken getUserToken(String userName)
I
think a few of the server calls do have
System.out.println/System.err.println commands that do end up in the
catalina.out file.
Joel
On 2013-06-17 16:59, Christopher Schultz
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
Joel,
>
> On 6/17/13 5:12 PM, joel wrote:
>
>> Thanks for the help.
I'm not an expert with tomcat management, There are no servlets. I don't
know what Threadlocal, doGet/doPost/etc are, so presumably haven't used
them.
>
> Eventually, everything is a servlet (or maybe a Filter in
certain
> cases). Even if your code does not include doGet/doPost, they
are
> likely being used under the covers.
>
>> No references are kept
to request,response, session, or stream objects. At login, a user
session token is stored: session.setAttribute("userToken", userToken);
This token also contains wrapper methods to make server calls.
>
> What
does that mean "make server calls"? Do you make those calls in
>
separate threads or anything like that?
Links:
------
[1]
http://gpgtools.org
[2] http://www.enigmail.net/
[3]
mailto:users-unsubscribe@tomcat.apache.org
[4]
mailto:users-help@tomcat.apache.org
We have precompiled tags which were compiled under 5.5.35 and don't work under 7.0.34. From
my investigation, it appears it's due to an interface change in JspSourceDependent. The return
type of getDependants() changed. For us the solution isn't as simple as recompiling for two
reasons: we have shipping products which plug into our tomcat based platform and some such
products target multiple versions of our platform, some of which are 5.5 based and some are
7.0 based.
Is this a bug? Shouldn't there be backward compatibility for precompiled tags? Is there anything
that can be done to get such existing tags working? I'm looking for any guidance on how to
move forward in addressing this issue.
Here is an example tag that exhibits the problem:
<%@taglib prefix="c" uri="http://java.sun.com/jstl/core_rt" %>
<%@tag dynamic-attributes="dynamicAttributes" %>
<%@attribute name="id" required="true" rtexprvalue="true" %>
<div id="${id}">
<table>
<c:forEach var="attribute" items="${dynamicAttributes}">
<tr><th>${attribute.key}</th><td>${attribute.value}</td></tr>
</c:forEach>
</table>
</div>
When referenced in a precompiled jsp like this...
<sample:javafree id="javafree.tag" randomkey="randomvalue"
anotherkey="anothervalue" />
...and all compiled against 7.0 but used in 7.0 (or 5.5/5.5), the resulting html looks like
this:
<div id="javafree.tag">
<table>
<tbody><tr><th>randomkey</th><td>randomvalue</td></tr>
<tr><th>anotherkey</th><td>anothervalue</td></tr>
</tbody></table>
</div>
However when compiled against 5.5 and used in 7.0, the resulting html looks like this:
<div id="">
<table>
</table>
</div>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Joel,
On 6/17/13 5:12 PM, joel wrote:
> Thanks for the help. I'm not an expert with tomcat management,
> There are no servlets. I don't know what Threadlocal,
> doGet/doPost/etc are, so presumably haven't used them.
Eventually, everything is a servlet (or maybe a Filter in certain
cases). Even if your code does not include doGet/doPost, they are
likely being used under the covers.
> No references are kept to request,response, session, or stream
> objects. At login, a user session token is stored:
>
> session.setAttribute("userToken", userToken);
>
> This token also contains wrapper methods to make server calls.
What does that mean "make server calls"? Do you make those calls in
separate threads or anything like that?
> When tomcat starts mixing sessions, it at least some of the time
> incorrectly maps the userToken with the user.
If you set the userToken a single time in a session and you always
pull it out of the session instead of getting it anywhere else, then
you should be okay with respect to that particular object.
Does the userToken have any request-oriented object references in it
(e.g. request, response, or streams of any kind)?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRv4bSAAoJEBzwKT+lPKRYYIAQAJM4LLlcJUaXXxV1l3YeVzlY
CVAZ1d/q2C6JnydmWlj3Byhidq5tnKRaKjLfoXfUbG+hkrf8+xgPwKSlwKCjE+KS
9lhDgpUNLMd0f4kXQr5cLknDtsliCvAaV1FnpDZeLPsDXIRUDLAYiuYvGGEZt+EO
KGo4oIFuuoKdwbV8XAmG2yumOkf+pMiXO7ZI7tfOz9EjX65Zxm/rADGzCF9aESAx
pH9XY2OMUT5sgOYMlRjgF4/d12ByaVFM5Kbw9TQMMKeawokBDNsz/A83idkvlLw9
WNLkKKx7zRMO634J85WKLQEv6NbbNNF5Xg1a+KMDNotGwGYfFsYh0NTWZfpu+UMf
t/ShPpb6Yw6/YPOgF5GoWXKfl4uG2m7XgkOEry2dVga9XJVJe/CqnKI607UMfOA3
SGdpuE+BDZxomIbP+8CJl7NskpisIcgTy/W2GOvUFE+S3w/R3H5CIOUtRSD366kV
mjbAoCVv8y5hwxOXUOD6wDa+1Cy16Lvmdg0vqjB89ggidtq+GtDdxbx7QM+eK4tQ
2wVZDBpw/Uc32qW3qgVaB+oN5KHpsiOdu1j/JVMcCI5Aq7EUWeskZcY62BJ0bhpF
UkgSx8oyK707x7YbPesupE99OoXpyMJVXEQH4C/3f0iEep2BJQSQVyuJK0XIl6f+
JndKzLPsVVtMSwzLBBse
=F83I
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Hi Chris,
Thanks for the help. I'm not an expert with tomcat
management, There are no servlets. I don't know what Threadlocal,
doGet/doPost/etc are, so presumably haven't used them. No references are
kept to request,response, session, or stream objects. At login, a user
session token is stored:
session.setAttribute("userToken",
userToken);
This token also contains wrapper methods to make server
calls. When tomcat starts mixing sessions, it at least some of the time
incorrectly maps the userToken with the user.
I'll start the process of
upgrading tomcat and hopefully that is all it takes (and hopefully it
doesn't introduce new problems).
Joel
On 2013-06-17 12:47, Christopher
Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Joel,
>
> On 6/17/13 12:01 PM, joel wrote:
>
>> Thanks for the
info! I'll look into making the upgrade. Can you advise how an
application bug can cause this when restarting tomcat will fix it? That
would help me wrap my mind around something that isn't imaginable,
yet.
>
> If you store a request object in a session, for example.
Another one
> is having a servlet-scoped variable that gets set in the
>
doGet/doPost/etc. method.
>
> There are other ways to shoot yourself in
the foot, but these are two
> of the most obvious (and common).
>
>
Other ways to leak information include, but are not limited to:
>
> - -
Sloppy ThreadLocal management
> - - Retaining a reference a request or
response object
> - - Retaining a reference to a servlet
Input/OutputStream
> - - Retaining a reference to a session
>
> Hope
that helps,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version:
GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
http://gpgtools.org
> Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
>
>
iQIcBAEBCAAGBQJRv0vAAAoJEBzwKT+lPKRY01IQAIDwohve5xSpLBN+IqVCUJDQ
>
fW8Iyqch5B6h0nNNQh+A5uxAtWDNnCRUb0PTVwuk3mSYiiDXq9XwhW0Z1zQmmV/Y
>
1J4WyiEJfksjDq4NQa0bH4rUh9wbvHu8beTihz73zN4ydHe/kyOTIiC9K0SBs1Dh
>
HvsjRrf/+jXkg8SNvTZGxHZ9wCMv2wuRA2SFYy5PJIOgjBEDrVzctxwSidcBlta6
>
FhQmTV2DJELBjbc9QPl5DXrsnGntb0T9gzvOuxhl4hWVkt2oIO2MUdYkPGV9APIi
>
rAH4/dJtXzhMs4laMFIsiLBt2eNx8zMJUUfW0wnj1zjfxWqg6chIdidlkqc/M6Bn
>
A3oC3V5QGLrdeONHmvelOqX+9st3OorrKBvk+JoIVzvxN2zeXQacYJGiOOI484Vc
>
HdbWdBrcAgk3PVwtOnR8NF+jCP0quDuiS5O9C3UpXjAr/F/azeVswJZImWVTElJO
>
LmhfRFBq/CaopNJGRRm3MWbbgTeTrPUxCw/S6SbUASHcQAh3eRboq04UvPm+BqWb
>
HRX65PLzio92rboIMKbPpVTc8sqDKRtoQ0k59vH8zsGQmF6WkpRi2MFoHkhdo2JQ
>
IrUSSrbYoJP5KF6GmjEqVfPVWXiKc5aWyWBG1O8ffcqZGqghCwK4/r6OEx9jFz6S
>
mW18XO3jD02az0rTZRGo
> =L4yS
> -----END PGP SIGNATURE-----
>
>
---------------------------------------------------------------------
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For
additional commands, e-mail: users-help@tomcat.apache.org
On 17/06/2013 20:35, Nick Williams wrote: > > On Jun 17, 2013, at 2:33 PM, Mark Thomas wrote: > >> On 17/06/2013 14:26, Nicholas Williams wrote: >>> On Jun 17, 2013, at 8:15, Nick Williams <nicholas@nicholaswilliams.net> wrote: >>> >>>> It seems obvious, but I couldn't find it mentioned in the spec, which concerns me. Hopefully I'm overlooking something. >>>> >>>> All <init-param>s in the (merged?) deployment descriptor are guaranteed to be picked up and placed in the ServletContext before any ServletContainerInitializers are triggered, right? >>>> >>>> Nick >>> >>> Sorry, I meant <context-param>s, not <init-param>s. Methinks I'm >>> operating on too little sleep. >> >> It is the logical way of doing things but I don't see any explicit language either. The best I could find was section 8.3 which implies in paragraph 3 that that the combined web.xml needs to have been processed before the SCIs are called. >> >> Mark > > Well at least I'm not going blind. > > So how does Tomcat do it? It adds all the context-params to the context before triggering the SCIs? org.apache.catalina.startup.ContextConfig The method of interest is left as an exercise for the reader. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
On Jun 17, 2013, at 2:33 PM, Mark Thomas wrote: > On 17/06/2013 14:26, Nicholas Williams wrote: >> On Jun 17, 2013, at 8:15, Nick Williams <nicholas@nicholaswilliams.net> wrote: >> >>> It seems obvious, but I couldn't find it mentioned in the spec, which concerns me. Hopefully I'm overlooking something. >>> >>> All <init-param>s in the (merged?) deployment descriptor are guaranteed to be picked up and placed in the ServletContext before any ServletContainerInitializers are triggered, right? >>> >>> Nick >> >> Sorry, I meant <context-param>s, not <init-param>s. Methinks I'm >> operating on too little sleep. > > It is the logical way of doing things but I don't see any explicit language either. The best I could find was section 8.3 which implies in paragraph 3 that that the combined web.xml needs to have been processed before the SCIs are called. > > Mark Well at least I'm not going blind. So how does Tomcat do it? It adds all the context-params to the context before triggering the SCIs? Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
On 17/06/2013 14:26, Nicholas Williams wrote: > On Jun 17, 2013, at 8:15, Nick Williams <nicholas@nicholaswilliams.net> wrote: > >> It seems obvious, but I couldn't find it mentioned in the spec, which concerns me. Hopefully I'm overlooking something. >> >> All <init-param>s in the (merged?) deployment descriptor are guaranteed to be picked up and placed in the ServletContext before any ServletContainerInitializers are triggered, right? >> >> Nick > > Sorry, I meant <context-param>s, not <init-param>s. Methinks I'm > operating on too little sleep. It is the logical way of doing things but I don't see any explicit language either. The best I could find was section 8.3 which implies in paragraph 3 that that the combined web.xml needs to have been processed before the SCIs are called. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Joel, On 6/17/13 12:01 PM, joel wrote: > Thanks for the info! I'll look into making the upgrade. > > Can you advise how an application bug can cause this when > restarting tomcat will fix it? That would help me wrap my mind > around something that isn't imaginable, yet. If you store a request object in a session, for example. Another one is having a servlet-scoped variable that gets set in the doGet/doPost/etc. method. There are other ways to shoot yourself in the foot, but these are two of the most obvious (and common). Other ways to leak information include, but are not limited to: - - Sloppy ThreadLocal management - - Retaining a reference a request or response object - - Retaining a reference to a servlet Input/OutputStream - - Retaining a reference to a session Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRv0vAAAoJEBzwKT+lPKRY01IQAIDwohve5xSpLBN+IqVCUJDQ fW8Iyqch5B6h0nNNQh+A5uxAtWDNnCRUb0PTVwuk3mSYiiDXq9XwhW0Z1zQmmV/Y 1J4WyiEJfksjDq4NQa0bH4rUh9wbvHu8beTihz73zN4ydHe/kyOTIiC9K0SBs1Dh HvsjRrf/+jXkg8SNvTZGxHZ9wCMv2wuRA2SFYy5PJIOgjBEDrVzctxwSidcBlta6 FhQmTV2DJELBjbc9QPl5DXrsnGntb0T9gzvOuxhl4hWVkt2oIO2MUdYkPGV9APIi rAH4/dJtXzhMs4laMFIsiLBt2eNx8zMJUUfW0wnj1zjfxWqg6chIdidlkqc/M6Bn A3oC3V5QGLrdeONHmvelOqX+9st3OorrKBvk+JoIVzvxN2zeXQacYJGiOOI484Vc HdbWdBrcAgk3PVwtOnR8NF+jCP0quDuiS5O9C3UpXjAr/F/azeVswJZImWVTElJO LmhfRFBq/CaopNJGRRm3MWbbgTeTrPUxCw/S6SbUASHcQAh3eRboq04UvPm+BqWb HRX65PLzio92rboIMKbPpVTc8sqDKRtoQ0k59vH8zsGQmF6WkpRi2MFoHkhdo2JQ IrUSSrbYoJP5KF6GmjEqVfPVWXiKc5aWyWBG1O8ffcqZGqghCwK4/r6OEx9jFz6S mW18XO3jD02az0rTZRGo =L4yS -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
Hi Mark, Thanks for the info! I'll look into making the upgrade. Can you advise how an application bug can cause this when restarting tomcat will fix it? That would help me wrap my mind around something that isn't imaginable, yet. Thanks! Joel On 2013-06-17 10:46, Mark Thomas wrote: > On 17/06/2013 16:32, joel wrote: > >> Hi, I'm using Apache Tomcat/6.0.24 running on centos and have several times observed a rare issue in which user sessions are "mixed". When this occurs, userA clicks on a link and is provided with userB specific content, content that should only be accessible to userB. When this "mixing" occurs, it seems to affect multiple sessions at the same time, ie userA and userB are not the only ones affected. Restarting tomcat fixed the problem. Does anyone know what causes this or how to prevent it? > > This is caused by an application bug in 99.9% of cases. > > There are known issues in 6.0.24 that could cause this. In any case, > given the number of security fixes since 6.0.24, an upgrade to 6.0.37 is > in order. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org
On 17/06/2013 16:32, joel wrote: > > > Hi, > > I'm using Apache Tomcat/6.0.24 running on centos and have > several times observed a rare issue in which user sessions are "mixed". > When this occurs, userA clicks on a link and is provided with userB > specific content, content that should only be accessible to userB. When > this "mixing" occurs, it seems to affect multiple sessions at the same > time, ie userA and userB are not the only ones affected. Restarting > tomcat fixed the problem. > > Does anyone know what causes this or how to > prevent it? This is caused by an application bug in 99.9% of cases. There are known issues in 6.0.24 that could cause this. In any case, given the number of security fixes since 6.0.24, an upgrade to 6.0.37 is in order. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
Hi, I'm using Apache Tomcat/6.0.24 running on centos and have several times observed a rare issue in which user sessions are "mixed". When this occurs, userA clicks on a link and is provided with userB specific content, content that should only be accessible to userB. When this "mixing" occurs, it seems to affect multiple sessions at the same time, ie userA and userB are not the only ones affected. Restarting tomcat fixed the problem. Does anyone know what causes this or how to prevent it? Thanks, Joel
On Jun 17, 2013, at 8:15, Nick Williams <nicholas@nicholaswilliams.net> wrote: > It seems obvious, but I couldn't find it mentioned in the spec, which concerns me. Hopefully I'm overlooking something. > > All <init-param>s in the (merged?) deployment descriptor are guaranteed to be picked up and placed in the ServletContext before any ServletContainerInitializers are triggered, right? > > Nick Sorry, I meant <context-param>s, not <init-param>s. Methinks I'm operating on too little sleep. Nick
It seems obvious, but I couldn't find it mentioned in the spec, which concerns me. Hopefully I'm overlooking something. All <init-param>s in the (merged?) deployment descriptor are guaranteed to be picked up and placed in the ServletContext before any ServletContainerInitializers are triggered, right? Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
Ja kub, Looks like you are re-inventing wheel here. All you are looking for is a fault tolerance system, you should consider exploring hystrix - latency and fault tolerance for distributed systems library. https://github.com/Netflix/Hystrix -Ravi ________________________________________ From: Ja kub [jjakub83@gmail.com] Sent: Thursday, June 13, 2013 1:11 AM To: Tomcat Users List Subject: Re: http request (no only session) replication in cluster Christopher Thx for response, I will inform guys from business about what You have written, and let them consider it Regards Jakub On Wed, Jun 12, 2013 at 4:10 PM, Christopher Schultz < chris@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jakob, > > On 6/11/13 5:04 PM, Ja kub wrote: > > requirement is system should be possible to process 160 req/sec > > (200 is better to multiply) and system is kind of failover proxy > > itself > > > > there are 2 backing webservices, each can answer max 20s, it there > > is timeout on first, I must call the second, if there is timeout on > > second I send soap fault to client, so usually it shouldn't be more > > than 20s per req, guys say that normally it is 7-10 > > seconds/request, but in worst case it is 2*20s*160 requests/s ~= > > 6400 pending requests (and according to deal we must fulfill worst > > case) > > If you have 2 member nodes and one of them starts to slow down, then > you'll see pretty much all requests re-tried on the second node, which > will slow down that one. I think you'll end up seeing a storm of > requests bouncing back and forth. > > Worse, the initial request will continue processing on the 1st node, > ignorant of the fact that the lb has given up and tried the other > node. It's just going to fall apart from there. > > Honestly, this should be able to be handled at your lb -- can't you > set a time-out there? > > > even if there are so many requests they are pending on sockets, I > > try to do it with NIO, asynchronous servlets and async cxf - both > > async cxf webservice is exposed by me, and I also call backing ws > > with async cxf I think even one tomcat on one server should be able > > to serve such 6400 pending requests with 160req/s, apart from proxy > > there are also 4-6 inserts into database (cli req, resp; 1st ws > > call, resp; 2nd ws call, resp > > > > how do You assess such architecture/attitude ? do You expect > > problems with async exposed webservice based on async servlet and > > NIO, and async cxf ws client ? afaik cxf use thread locals, are > > they all right with tomcat async servlets ? (I don't define > > threadlocals by myself, only cxf possibly does) > > It's not a socket-resource issue, it's a raw work-load issue: you have > a large amount of load and it looks like you can't handle it very > well. I would recommend more nodes, first, and then seriously consider > whether re-trying on a second node is appropriate if the first node > takes too long. > > What you should probably do is actually profile your code to find out > what is taking so long. Using tricks like ThreadLocals can shed > microseconds off of a request, not whole seconds. > > You might want to consider whether you can do less work during a > request -- perhaps split a single transaction into more than one. Or, > just acknowledge that sometimes a transaction can take 10-20 seconds > (or 50?) and manage the clients' expectations. > > You also need to find out where your bottleneck is: RDBMSs, slow > disks, slow network links, etc. can all be much more significant than > things like software stack and exact implementation of your code. If > you are missing an index on a relational table, transactions that > should take a second or two can take tens of seconds. > > Start there: profile your application, find out what is slow, and fix > that. Don't try to work-around the problem with surprising > transactional re-tries, because they likely won't work the way you > hoped. Hey, once you fix your performance problem, perhaps you won't > need additional hardware. Also, your users will be very happy to see a > speed improvement. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRuIFyAAoJEBzwKT+lPKRYr+4QAL7UCQvZ/CBIueIqhFDLkZ57 > v0uWcuukEtT8/8dNUBW2SGSE4OwDyH41Nsx7ZVo4W+lTnzduVbjXSvU4lXNDiY19 > 9MgpwuxZWlUxHAgOQ5NODIFwrHQK2GYMe8+Qo8OBVf6lOhVdB4PS/7XM7lrsnWBn > rpojl4rPm7+esciZPB1q15+PxCbgh4uGsI4KCXyZiW/gz/dLC2v8u6QiYfqoXgov > iutYtII+7f1E6I+Ag3LjmQwrzY7pRpHrotcJ4aCpyOs9EHTavKf3mapwY2HiOP+t > G9qwGuq5tUJhkBzF5Vdvqf+lCbdJHkQtLW3Z4vL4/XTK7SVSvjipFhsttZF4TII6 > 6QVQmjCJZRYdPDegzB+NVaCxPkdZLLdwHNFFfsZGabdTQDkAKOEXQiYjBqJ9n5nX > WRHvYLQtyGEj1e+0zqwCihRHie2TbfwdggtCoVaOF+8Zpguv3K9VRHwvFA/miA1i > JkYCfxKjyF/RoCyB4wZqCi5VsJjztQpq6uDQiUG0CACY1491sB35M+Vkqm3jqRbh > 0HXs1ckqZsw+2Y013kpCVs0eipOst5GD6XqXr6LTT/fQwEYWa3uVTk3/h2xDd9BT > DlTZrs1CNhqMBjNqUDUFkiiempf9kFkQhrao50CAilix95/VhdWkDjFcFSKKQ0/J > EkcONNIioMTN7cWzKNHf > =miI6 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
Ah! It's not set. I'll give that a shot and see how it works. Thanks for the pointer! --p. On Fri, Jun 14, 2013 at 3:18 PM, Christopher Schultz < chris@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Patrick, > > On 6/14/13 4:55 PM, patrick conant wrote: > > I’ve got Tomcat configured with a JNDI Realm talking to Microsoft > > Active Directory over LDAP. It works perfectly when > > ActiveDirectory works; but when ActiveDirectory gets flaky (which > > it sometimes does), Tomcat doesn’t handle it well. In one > > particular case, I’ve got one thread stuck trying to talk to > > ActiveDirectory and 199 additional threads waiting for the first > > thread to release its lock on the JNDIRealm. Relevant bits of the > > stack dump are below. > > > > My first question is: is there a way to configure the JNDIRealm to > > be more fault-tolerant? It looks like I could add an alternateURL > > attribute -- but in this case, it seems like the connection is hung > > and the JNDIRealm doesn't recognize a failure, so it wouldn't fail > > over to the alternateURL. Is there anything else I can do to allow > > the JNDIRealm to recover from this situation? > > > > My second question is: really -- authentication is serialized? > > Then I realized that the big bold TODO in the docs would address > > this problem. ( > > > http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/realm/JNDIRealm.html > ). > > > > > Bummer. I ought to get coding on that... > > What is your "timeLimit" attribute set to on this <Realm>? The default > timeout is infinite... > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRu4ipAAoJEBzwKT+lPKRYKjAP+wY9DQmicgVl7wYJ+ZwJd9Dp > JVZHaxS1zaG4mAARyRcfH6Zgq47hYoroIoWEajV0VP3FVzux4M6zhFRtqu8LDthm > jq7OlrmlQufUfgqqGIAUqg6BaDscl67VohRAS/odJpyItAQ11KKoxCd+A6kr1Slm > RJHBirpyURX3u9p/SbB4G9Jz2cMELwckzT9OQsidZ7ylmb1Y+CXbAntzDmMEuf7/ > p4dDHOKkc4FipagO4dJOpDw+WUYgSoqhCVDaP5wf6/gpZU5oPU/u0MY3drnI0lhE > ofAdnGGntgORp9JpvtnZeyTm8PWLfbRmWqRVH6kDczzgoUoRRcoMJqdg9g4f7Z9A > k9a+WDazPbapMXKK+tJ0gG4KDD7x1jy6hzOjAI8iz59kRrDoRS/ESJzsIg0IaWMh > qewLMthnjPoo7P+CRCSxKBTbPb2sbYEquWQ0M9y+0BEdgTqOpO7fDG6RVMLJFnhP > Mmf0HWKN0JLBgIT5DU7wpCwFONyGOmHF6poSIOPRtjYprXv4EP9Q7trS7BrLPg2h > a4vXAUz5ihQJ6tyz7aSPS7P+e/sd2Ha1x/er+kGou49dtdX8MxPhh3ZB+ATpYJBP > /ZPqf3ERo+8AnCv4ZHhuJBn2uhyFNc2XacoNS1LUGIfrJR4AVYli5ZVJP8cqA8E3 > i+C6pIQobmKzBtT9Uumd > =4AXj > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Patrick, On 6/14/13 4:55 PM, patrick conant wrote: > I’ve got Tomcat configured with a JNDI Realm talking to Microsoft > Active Directory over LDAP. It works perfectly when > ActiveDirectory works; but when ActiveDirectory gets flaky (which > it sometimes does), Tomcat doesn’t handle it well. In one > particular case, I’ve got one thread stuck trying to talk to > ActiveDirectory and 199 additional threads waiting for the first > thread to release its lock on the JNDIRealm. Relevant bits of the > stack dump are below. > > My first question is: is there a way to configure the JNDIRealm to > be more fault-tolerant? It looks like I could add an alternateURL > attribute -- but in this case, it seems like the connection is hung > and the JNDIRealm doesn't recognize a failure, so it wouldn't fail > over to the alternateURL. Is there anything else I can do to allow > the JNDIRealm to recover from this situation? > > My second question is: really -- authentication is serialized? > Then I realized that the big bold TODO in the docs would address > this problem. ( > http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/realm/JNDIRealm.html). > > Bummer. I ought to get coding on that... What is your "timeLimit" attribute set to on this <Realm>? The default timeout is infinite... - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRu4ipAAoJEBzwKT+lPKRYKjAP+wY9DQmicgVl7wYJ+ZwJd9Dp JVZHaxS1zaG4mAARyRcfH6Zgq47hYoroIoWEajV0VP3FVzux4M6zhFRtqu8LDthm jq7OlrmlQufUfgqqGIAUqg6BaDscl67VohRAS/odJpyItAQ11KKoxCd+A6kr1Slm RJHBirpyURX3u9p/SbB4G9Jz2cMELwckzT9OQsidZ7ylmb1Y+CXbAntzDmMEuf7/ p4dDHOKkc4FipagO4dJOpDw+WUYgSoqhCVDaP5wf6/gpZU5oPU/u0MY3drnI0lhE ofAdnGGntgORp9JpvtnZeyTm8PWLfbRmWqRVH6kDczzgoUoRRcoMJqdg9g4f7Z9A k9a+WDazPbapMXKK+tJ0gG4KDD7x1jy6hzOjAI8iz59kRrDoRS/ESJzsIg0IaWMh qewLMthnjPoo7P+CRCSxKBTbPb2sbYEquWQ0M9y+0BEdgTqOpO7fDG6RVMLJFnhP Mmf0HWKN0JLBgIT5DU7wpCwFONyGOmHF6poSIOPRtjYprXv4EP9Q7trS7BrLPg2h a4vXAUz5ihQJ6tyz7aSPS7P+e/sd2Ha1x/er+kGou49dtdX8MxPhh3ZB+ATpYJBP /ZPqf3ERo+8AnCv4ZHhuJBn2uhyFNc2XacoNS1LUGIfrJR4AVYli5ZVJP8cqA8E3 i+C6pIQobmKzBtT9Uumd =4AXj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
I’ve got Tomcat configured with a JNDI Realm talking to Microsoft Active
Directory over LDAP. It works perfectly when ActiveDirectory works; but
when ActiveDirectory gets flaky (which it sometimes does), Tomcat doesn’t
handle it well. In one particular case, I’ve got one thread stuck trying
to talk to ActiveDirectory and 199 additional threads waiting for the first
thread to release its lock on the JNDIRealm. Relevant bits of the stack
dump are below.
My first question is: is there a way to configure the JNDIRealm to be more
fault-tolerant? It looks like I could add an alternateURL attribute -- but
in this case, it seems like the connection is hung and the JNDIRealm
doesn't recognize a failure, so it wouldn't fail over to the alternateURL.
Is there anything else I can do to allow the JNDIRealm to recover from
this situation?
My second question is: really -- authentication is serialized? Then I
realized that the big bold TODO in the docs would address this problem. (
http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/realm/JNDIRealm.html).
Bummer. I ought to get coding on that...
Any thoughts appreciated!
Thanks,
Pat.
Here’s one of the 199 blocked threads:
"http-8080-200" daemon prio=10 tid=0x00007f1de0073800 nid=0x7f1e waiting
for monitor entry [0x00007f1dbcd8c000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1044)
- waiting to lock <0x0000000780053fe0> (a
org.apache.catalina.realm.JNDIRealm)
at
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:945)
at
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:181)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:523)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:679)
Here’s the blocking thread:
"http-8080-4" daemon prio=10 tid=0x00007f1de000d800 nid=0x2332 in
Object.wait() [0x00007f1e1c2d9000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007843fdc38> (a com.sun.jndi.ldap.LdapRequest)
at com.sun.jndi.ldap.Connection.readReply(Connection.java:447)
- locked <0x00000007843fdc38> (a com.sun.jndi.ldap.LdapRequest)
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:358)
- locked <0x00000007843fdbd8> (a com.sun.jndi.ldap.LdapClient)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:210)
- locked <0x00000007843fdbd8> (a com.sun.jndi.ldap.LdapClient)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2685)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2593)
at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2567)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1932)
at com.sun.jndi.ldap.LdapCtx.doSearchOnce(LdapCtx.java:1924)
at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1317)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127)
at
javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:140)
at
org.apache.catalina.realm.JNDIRealm.bindAsUser(JNDIRealm.java:1562)
at
org.apache.catalina.realm.JNDIRealm.checkCredentials(JNDIRealm.java:1416)
at
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1092)
- locked <0x0000000780053fe0> (a org.apache.catalina.realm.JNDIRealm)
at
org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:977)
at
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:181)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:523)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:679)
* *
* *
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André, On 6/14/13 3:17 AM, André Warnier wrote: > Carl Dreher wrote: >> I have Tomcat 7.0.26 running on Window7 Pro. I also have Tomcat >> 7.0.40 running on a Windows 7 Home Premium. Both have the same >> website. (Obviously, I'm doing some testing.) >> >> In the website, a user logs on and the user ID is kept in the >> session. In one of the JSP pages I have some JavaScript >> attached to an html button <input type="button" name="" >> value="blah blah blah" >> onclick="window.location='/MySite/MyAction.do'"> (I'm using >> Struts.) Now, here is were it gets strange... >> >> During testing, I found that IE8 and IE9 both run fine against >> Tomcat 7.0.26. By that I mean, after the user logs on, the user >> ID is kept in the session. After navigating around the site, if >> the user then clicks on the above button, the Struts Action >> class "MyAction.do" is able to find the user ID in the session. >> The same is true of IE9 against Tomcat 7.0.40. >> >> But if I do the above with IE8 against the site on Tomcat >> 7.0.40, the user ID in the session is empty. >> >> To summarize, | IE8 | IE9 >> ----------------------------------------------------------- >> Tomcat 7.0.26 | ok | ok >> ----------------------------------------------------------- >> Tomcat 7.0.40 | fail | ok >> ----------------------------------------------------------- >> >> Any ideas where to start looking? >> > > Yes. I would recommend, first of all, that you install some add-on > on the IE side, which can display the conversation between IE and > server (HTTP headers etc.). (I know of Fiddler2, but there might > be others). Then run your check once on each, and compare > requests/responses/headers. +1 My first reaction is that the session id cookie is being lost, and the URL being used for window.location=... has not been run through response.encodeURL(). Carl, you can use one of any number of fine JSP tag libraries (JSTL, Struts own taglibs, etc.) to do the equivalent of this (example uses JSTL): <input type="button" name="" value="..." onclick="window.location='<c:url value="/MyAction.do" />'" /> Note that I assumed /MySite was your context path and so I removed it from the <c:url> call: <c:url> knows the context path and will insert it into the URL automatically. If you are running as ROOT context and the /MySite is actually part of the local URI, you'll obviously need to add that back in. Whether this fixes your problem or not, you should be doing it all the time for two reasons: 1. Sessions will continue to work when users have disabled cookie-based session tracking 2. Your webapp will continue to work if you change its name (say, from /MySite to /MyOtherSite) Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuzv9AAoJEBzwKT+lPKRYPtUP/RKSTtMsu9fDJ4IIdxQ1lczF RuMR0yWFS2NJ+9bFOp+JBguj2mPGDXIXsh5ylZC0BxuUr7nc/XmBqQHDrvhu+7/q U9NWqJh5CucSmNqioszEQ61tCaRqK39z9NpQpw3VPf14ShPAxb4Rlre9hba2oCR4 eohVo40hmGjmH4Gn5qm7AR3GTxX71Rs/Lwb/VItUurUpixCv8kNk5a4xNL0uzkcC YCDnzEXU5P1S4Ec2qqqQDT1wbCEfYDWtSh70/WxRN3GZgXT6RUUX59YeeQYJueUs 9vFAVBXRhouMm/qpWlYIYVch1ynHINAB3srgcUA7u3ViGgYTM3x+7PLM5zA2UpJ7 Vs7iSAf8uodLw+kmWj1fWeeKRHVrAmqW4V5wD/FMD+PSqTR95elzsEvw8oxSAsak HEZXpgSo+UXrbk0zU8pQ7yct4AAm23ijOzTNVdIi8V9vw08ALHAs0iAvUyxWkvuf zOBNEP38esHMpgTOH4/ul8B8L7mnL3+6T4m6YFz6lUnD2SbZOjYpU4Y4lgBcoYZd gnn53Xu6eN3U9jMSgNNpR2YP/G9j/FUYPW+Up4Pe97bFHYgD07AJ15zxxCX47htb jlfcqXa85z+L0BxWw5TGUepFFpNXgWQEcgoKhEsn+CWVJZLh72czKFZRyr8UxiF0 0Oboz8dhXnas66JdIiXo =oaRx -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
2013/6/14 Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) <anigoyal@cisco.com>: > Hi > I have two service running in tomcat. > First service 'catalina' is having connector port 80, 443, 8080 and 8444. > Second service 'catalina_advance' have connector port 8081 and 8444. > > For catalina_advance, I entered a new tomcat access log file with configuration > <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%t %a %h %u %l %p %m %U %H %s %b %D" prefix="localhost_access_log" rotatable="false" suffix=".txt"/> > > Now whe I hit the url http://ip-address:8081/context > The port print in access log file is 8081 > > When when I hit the url https://ip-address:8444/context > The port always print as 443. This is not what you were writing in your e-mails earlier. > > Why this is happening > When is this happening? Is it reproducible with simple example web application on a clean Tomcat installation? It is not your first e-mail here, but again you lack the details. I am sure there are a number of "bug reporting guidelines" on the net, but at least please read these: https://issues.apache.org/bugzilla/page.cgi?id=bug-writing.html --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
Hi I have two service running in tomcat. First service 'catalina' is having connector port 80, 443, 8080 and 8444. Second service 'catalina_advance' have connector port 8081 and 8444. For catalina_advance, I entered a new tomcat access log file with configuration <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%t %a %h %u %l %p %m %U %H %s %b %D" prefix="localhost_access_log" rotatable="false" suffix=".txt"/> Now whe I hit the url http://ip-address:8081/context The port print in access log file is 8081 When when I hit the url https://ip-address:8444/context The port always print as 443. Why this is happening -Anil
Carl Dreher wrote: > I have Tomcat 7.0.26 running on Window7 Pro. I also have Tomcat 7.0.40 > running on a Windows 7 Home Premium. Both have the same website. > (Obviously, I'm doing some testing.) > > In the website, a user logs on and the user ID is kept in the session. > In one of the JSP pages I have some JavaScript attached to an html button > <input type="button" name="" value="blah blah blah" > onclick="window.location='/MySite/MyAction.do'"> > (I'm using Struts.) Now, here is were it gets strange... > > During testing, I found that IE8 and IE9 both run fine against Tomcat > 7.0.26. By that I mean, after the user logs on, the user ID is kept in > the session. After navigating around the site, if the user then clicks > on the above button, the Struts Action class "MyAction.do" is able to > find the user ID in the session. > The same is true of IE9 against Tomcat 7.0.40. > > But if I do the above with IE8 against the site on Tomcat 7.0.40, the > user ID in the session is empty. > > To summarize, > | IE8 | IE9 > ----------------------------------------------------------- > Tomcat 7.0.26 | ok | ok > ----------------------------------------------------------- > Tomcat 7.0.40 | fail | ok > ----------------------------------------------------------- > > Any ideas where to start looking? > Yes. I would recommend, first of all, that you install some add-on on the IE side, which can display the conversation between IE and server (HTTP headers etc.). (I know of Fiddler2, but there might be others). Then run your check once on each, and compare requests/responses/headers. There have been over the years (and there still are) so many quirks/bugs/inconsistencies between IE versions (and patch levels within versions), that I would start there with any issue of this nature. I'm not saying that this /is/ the problem here, but first things first. It would not be too surprising if for some reason at some point, IE8 stops sending back the session cookie, causing Tomcat to create a new session, without user-id. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
I have Tomcat 7.0.26 running on Window7 Pro. I also have Tomcat 7.0.40
running on a Windows 7 Home Premium. Both have the same website.
(Obviously, I'm doing some testing.)
In the website, a user logs on and the user ID is kept in the session.
In one of the JSP pages I have some JavaScript attached to an html button
<input type="button" name="" value="blah blah blah"
onclick="window.location='/MySite/MyAction.do'">
(I'm using Struts.) Now, here is were it gets strange...
During testing, I found that IE8 and IE9 both run fine against Tomcat
7.0.26. By that I mean, after the user logs on, the user ID is kept in
the session. After navigating around the site, if the user then clicks
on the above button, the Struts Action class "MyAction.do" is able to
find the user ID in the session.
The same is true of IE9 against Tomcat 7.0.40.
But if I do the above with IE8 against the site on Tomcat 7.0.40, the
user ID in the session is empty.
To summarize,
| IE8 | IE9
-----------------------------------------------------------
Tomcat 7.0.26 | ok | ok
-----------------------------------------------------------
Tomcat 7.0.40 | fail | ok
-----------------------------------------------------------
Any ideas where to start looking?
- Carl Dreher
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jane,
On 6/13/13 6:44 PM, Jane Muse wrote:
> I'm using the standard implementation of Realm. Here's the code
>
> //Validate passwords try { if (oldTomcatPassword != null &&
> !"".equals(oldTomcatPassword.trim())) { TomcatConfig tconf =
> TomcatConfig.getInstance(); String digestAlg =
> tconf.getTomcatPwdEncryptionType(); String encryptedOldPwd =
> oldTomcatPassword; if (digestAlg != null) encryptedOldPwd =
> RealmBase.Digest(oldTomcatPassword, digestAlg); if
> (!encryptedOldPwd.equals(tconf.getEncryptedTomcatPwd(tomcatUserName)))
> { errors.add("incorrectPwd", new
> ActionError("error.password.incorrect")); } }
I'm not sure this is any different than the built-in Tomcat
digest-based realms. Why not just use the available ones and discard
your own realm?
> As I said, it no longer compiles with catalina.jar from Tomcat
> 7.0.41. This is not a surprise, that the signature would change,
> and I changed the code accordingly. Now it is:
>
> encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg,
> encodedType);
>
> Compiles fine now.
>
> . However, when I build with ant, it says actual and formal
> argument lists differ in length. I don't know why there's an actual
> and a formal argument list. I swapped out catalina.jar.
So, it complies "fine" except not when you build with ant? In what
situation does it compile "fine", then?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRuoGcAAoJEBzwKT+lPKRYeiYP+gI32KTIuZ5KO2B6GSthwTHl
+C30U4F16Wy1TGRuE5x876hlD/DKQP0DCzfk8D2rUsdQ/GqujQpt28hgtKHdBzij
ffHjs90S4lawDjiAxZyU6ZeiHT6g/r66gtCoQXMbN/s8Geur433XqLDWHDHIzloi
HpZDbLbbeDr+X06UYir037Xt34fMRAyahDCrCW25nJIOaPE/7ckAeiOsDjbBYWx1
G1/KJ5iE3WfysiERnmh7sFH0wt1g5b2B6BmmbNUGKP8lZNdpbmT8GeCcKfS3SR7e
J+onHNVcxEihwdZ1+5121npQlL9F4rxenO3u6StcLqYowL+++ysYt+wb2J9pI69E
Mw2Cpt83Ig1FtDnXSDd4g5jvj98yaZlqxAkT0JEDY6sHW70CpATJrFLoUwIHzAtE
VmRjVBDI5oVCOaGbz6pY53ZnM3eSrG/CiU4OVyzSAH9geKc093poRoE0pOiwGFIx
v1iG4Nj+LAsOPQjHyBPqtmd10htSxoScvy6tcVleava1uonSazsWKJbz4HDRv4ht
H+f+CC6KAfraMVWkCegB9PPxiWcfUnzeo49EfKWcNPspsIUCWYaXR90yvxYlssjb
jqlPp1sc1K7js6aTxeddTtmFPXXhpkFfs0UNmKJ0jZkd0IMQCVQt7dal26/JhbTY
I/sOTgQ+9mYooxZk9YkO
=S8rU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Hello, I do not think destination NAT is good solution because it works on TCP layer and knows nothing about domain names and URLs (both are application level (http) knowledge). So you would need to use separate IP/port for that and in case you have it you can bind tomcat there directly) So application-layer forwarding proxy (nginx, squid, apache) is way to go. Hardware cisco solutions could handle it too but I they are too big for such a simple task (unless you have really many users) Ilya >-----Original Message----- >From: Martin Gainty [mailto:mgainty@hotmail.com] >Sent: Friday, June 14, 2013 2:28 AM >To: Tomcat Users List >Subject: RE: forward request by changing the port in request url > >for IP Redirecting and or automatic Network Address Translations (e.g. Port >80 redirects to Port 81) > >you will need a proxy server > >please contact support@cisco.com > > >for product and service options > > > >Viel Gluck >Martin > > >> i have two service running under tomcat. One service is default i.e. >> catalina on port 8080 and 8443 second service is catalina_new on port 8081 >and 8444. >> >> i have application abc.war deployed in webapps_new service which is >running on port 8081. This application is not there in webapps. >> i want if any request coming on port 8080 for application abc, it is >> forwarded to port 8081.(same for ssl port 8443->8444) Is there any way to do >the same. >> >> Thanks >> Anil > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
I'm using the standard implementation of Realm. Here's the code
//Validate passwords
try {
if (oldTomcatPassword != null && !"".equals(oldTomcatPassword.trim()))
{
TomcatConfig tconf = TomcatConfig.getInstance();
String digestAlg = tconf.getTomcatPwdEncryptionType();
String encryptedOldPwd = oldTomcatPassword;
if (digestAlg != null)
encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg);
if (!encryptedOldPwd.equals(tconf.getEncryptedTomcatPwd(tomcatUserName))) {
errors.add("incorrectPwd", new ActionError("error.password.incorrect"));
}
}
As I said, it no longer compiles with catalina.jar from Tomcat 7.0.41. This is not a surprise,
that the signature would change, and I changed the code accordingly. Now it is:
encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType);
Compiles fine now.
. However, when I build with ant, it says actual and formal argument lists differ in length.
I don't know why there's an actual and a formal argument list. I swapped out catalina.jar.
188: error: method Digest in class RealmBase cannot be applied to given types;
[javac] encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType
);
[javac] ^
[javac] required: String,String
[javac] found: String,String,String
[javac] reason: actual and formal argument lists differ in length
[javac] 2 errors
[javac] 1 warning
-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
Sent: Thursday, June 13, 2013 1:41 PM
To: Tomcat Users List
Subject: RE: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:JMuse@rocketsoftware.com]
> Subject: RE: Class cast exception when starting tomcat 7.0.1
> I had catalina.jar in WEB-INF/lib.
Very, very bad move.
> It's needed because we have an implementation of Realm to store an
> encrypted tomcat password users enter in the webapp.
Your custom implementation of Realm should be in Tomcat's lib directory, not the webapp's.
See:
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#What_is_a_Realm?
Such a Realm should not be tied into the operation of any webapp, other than configuring the
webapp to use it.
> If I remove it and add the catalina.jar from tomcat_home/lib to the
> classpath
Not sure what you mean by adding it to the classpath; please explain.
> I have to change the signature from
> org.apache.catalina.realm.RealmBase.Digest(String, String) to
> org.apache.catalina.realm.RealmBase.Digest(String, String, String).
That's because internal Tomcat APIs often change between levels. You certainly cannot count
on using an older version of Realm with a newer Tomcat (or vice versa).
> Should I not be writing code that needs classes from catalina.jar?
It would certainly be desirable not to be dependent on internal Tomcat classes. Why do you
think a Realm should be storing a password (encrypted or not) anywhere? A Realm would normally
be reading a password from some controlled storage, not writing to it.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Hello, What is "request for application"? How would any software know this request is for abc app? You should use different URLs (servlet contexts) or different domain names. Then you may install nginx or apache or squid or something else that would forward your requests to the following tomcats. But you need to configure tomcat valve to store remote_addr. I will give you an example for nginx and domain names. Say, your DNS zone is "example.com." You create 2 subdomains "abc.example.com" and "def.example.com" both with same IP (A record). You install nginx on it listening port 80. You configure it to pass requests for abc.example.com to localhost:8080 and requests for def.example.com to 8081. You open browser and navigate to abc.example.com. Nginx accepts your request and makes request to localhost:8080 where tomcat with app abc sits. Tomcat answers to nginx and it forwards it to you. That is pretty common solution. Ilya Kazakevich, Developer JetBrains Inc http://www.jetbrains.com "Develop with pleasure!" >-----Original Message----- >From: Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) >[mailto:anigoyal@cisco.com] >Sent: Thursday, June 13, 2013 10:00 PM >To: Tomcat Users List >Subject: forward request by changing the port in request url > >i have two service running under tomcat. One service is default i.e. catalina >on port 8080 and 8443 second service is catalina_new on port 8081 and 8444. > >i have application abc.war deployed in webapps_new service which is >running on port 8081. This application is not there in webapps. >i want if any request coming on port 8080 for application abc, it is forwarded >to port 8081.(same for ssl port 8443->8444) Is there any way to do the same. > >Thanks >Anil --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
you can swap out one jar for another Ant has no idea which container it is communicating with unless you tell it catalina.jar is tied to the Servlet Spec so you cannot change catalina unless you change the accompanying Servlet Spec so you've already done that why not write a Quick and Dirty ant taskdef I'll pick this up on users@ant.apache.org Viel Gluck Martin Gainty ______________________________________________ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: JMuse@rocketsoftware.com > To: users@tomcat.apache.org > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Date: Thu, 13 Jun 2013 20:19:07 +0000 > > I had catalina.jar in WEB-INF/lib. It's needed because we have an implementation of Realm to store an encrypted tomcat password users enter in the webapp. If I remove it and add the catalina.jar from tomcat_home/lib to the classpath, I have to change the signature from org.apache.catalina.realm.RealmBase.Digest(String, String) to org.apache.catalina.realm.RealmBase.Digest(String, String, String). Then the code compiles ok, but I get this error when building with ant to make a war file: > > error: method Digest in class RealmBase cannot be applied to given types; > [javac] encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg,null); > > Should I not be writing code that needs classes from catalina.jar? > > Thanks, > > Jane > > -----Original Message----- > From: Christopher Schultz [mailto:chris@christopherschultz.net] > Sent: Thursday, June 13, 2013 11:09 AM > To: Tomcat Users List > Subject: Re: Class cast exception when starting tomcat 7.0.1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Jane, > > On 6/13/13 12:38 PM, Jane Muse wrote: > > In the archives I thought the only unreleased versions would be > > specified "beta". Please let me know if this is not the case. > > I'll admit it's not clear from the version number which versions are beta, released, etc. You have to look at the ChangeLog: > > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html > > Each release contains a release date and (optionally) a comment on the quality of the build. The first non-beta version of Tomcat 7.0.x was 7.0.6. Tomcat 7.0.1 (distinct from 7.0.10) was actually "not released" > probably because it was broken for some reason. > > When the Tomcat team rolls a release, there is a vote. If there aren't enough "yes" votes (or any "no" votes), the release is abandoned but the number isn't re-used. > > Anyhow, there's no reason to attempt to migrate from Tomcat 6.0.x to Tomcat 7.0.x by shooting for an "early" version of Tomcat 7.0.x: you should go for the latest. > > Also, if you mistype and say "Tomcat 7.0.1" instead of "Tomcat 7.0.10" > or "Tomcat 7.0.4" instead of "Tomcat 7.0.40" (or "Tomcat 7.0.41"), don't get an offended when people tell you you are doing it wrong. > Just say "whoops, I meant 7.0.40" and move on. > > Back to your original problem... have you modified the Tomcat 7 installation in any way -- other than dropping your WAR file/exploded WAR into the webapps/ directory)? > > Also, do you have any Tomcat-related JAR files in your webapp's WEB-INF/lib directory? > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRugqsAAoJEBzwKT+lPKRYkwcQALdDoGGk6ZNHg82Ow8vTjjrY > dO/70UaIg69t4TsgIJApzd+ReSMbzrThby4Ok+EkYOEXLC1tZgbbQpTQdx0sjqXc > k7fJl9oRQ/O9UP4lj+PR1iWL0zTX/Ze+eTQLIHiJ6rpNnyqgSOnZujsev1lbbaUZ > A2w8GwiWOPvA17MIQUio1Rr/OKd6s7/02EKJQwbxIRoBh4jdaTalgJXCBKb5+60p > EnNMautisYXQXrdE2hUhMgFX5EIyqPP4PZYxe2EKRRHlGuXnzybYJnuyxDLtGLY7 > nTpOfy5LA5xuFLHEruHm7ARUo6Hb8AH2Qvi5saXDsp+6ddh6Fy4Id4JaWODk16Zl > KbPQXk1QjZayw8/nmFkr2gWJc8pGYQMzmeCqSxiJ8FqcrXo/bTq4GJwFazqK4cvE > xfQDLyCNXaNdbskJ3rM336173+j7spUhrVlS8LyZ7B7bRPPOzxt5CmOZ2b3Y5Ti+ > uBTc1YUXQ74/gjoZCRet4xtaGwRfKXARVSebP6+33AtneOsAlbXejmz545ccmUWl > T/9c31jchDw+JlpX04KPu5hJzAb+/Jk3HdVG6LGDrB4oKyxcJcmzvREDXzVt+L5q > aPHhnAm8pAHYn1nSAR8k15NL61zDr16CC4ffzWu26c9DfSt9xq3XTg0ESPFv0U4J > kxt8hkkwFdx5ZbXxnFgb > =nulS > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[� \�\��][��X��ܚX�P �X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\��Z[ �X�] �\X�K�ܙ�B�
for IP Redirecting and or automatic Network Address Translations (e.g. Port 80 redirects to Port 81) you will need a proxy server please contact support@cisco.com for product and service options Viel Gluck Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > From: anigoyal@cisco.com > To: users@tomcat.apache.org > Subject: forward request by changing the port in request url > Date: Thu, 13 Jun 2013 18:00:12 +0000 > > i have two service running under tomcat. One service is default i.e. catalina on port 8080 and 8443 > second service is catalina_new on port 8081 and 8444. > > i have application abc.war deployed in webapps_new service which is running on port 8081. This application is not there in webapps. > i want if any request coming on port 8080 for application abc, it is forwarded to port 8081.(same for ssl port 8443->8444) > Is there any way to do the same. > > Thanks > Anil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Steve, On 6/13/13 5:27 PM, Steve Nickels wrote: >>> I figured out the problem. The error was due to my system >>> rebasing the libeay32.dll library from its desired base address >>> of 0xFB00000. According to OpenSSL documents, this is supposed >>> to generate a specific error message of >>> FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED, but >> because I wasn't >>> seeing that, I didn't think that was the problem. >> >> Interesting. Do you think it was being swallowed-up somewhere? >> Like I said, tcnative/FIPS hasn't gotten a huge amount of >> exposure. > > I think the error message issue might be a problem with OpenSSL > itself. As far as I can tell, tcnative is simply parroting back > the error message that OpenSSL gives it. It is, but the function we are using says it gets the "first" error from the error queue. I suppose we could drain the entire error queue looking for all messages and concatenate them together or something. We aren't inspecting the entire error queue. >> Do you think there are ways it could be improved? Better error >> checking, etc.? I implemented it as simply as I possibly could. > > The biggest problem seems to be that something in Tomcat on Windows > is interfering with OpenSSL's normal base address request > (0xFB00000). Normally this doesn't matter, but with the FIPS > build, if the base address of the library is moved from what it > expects, the result is a fingerprint error when FIPS mode is > enabled. This could be a problem on *NIX as well -- any library may be re-located by the loader for any reason. > I ran the openssl utility on the same system as Tomcat, and > Process Explorer shows that its copy of libeay32.dll stays at the > correct address. Additionally, I tested the FIPS-compatible > libeay32.dll on a different server with Tomcat, and had the same > problem. This seems to indicate that the memory address issue is > specific to Tomcat, not the server. Or running within a JVM which has a significant amount of native code that gets loaded first, which may cause the loader to re-locate the library when it finally gets loaded. Any interest in trying some Java-based testing using libtcnative? > I can't tell from Process Explorer why libeay32.dll is being > rebased (I didn't see any other libraries under tomcat7.exe that > were obviously taking up the same address space). I think it's > going to take someone with more experience with both Windows and > Tomcat than I to figure that one out. I suppose it might be worthy > of a bug report, at least. That would be good -- bug reports have more visibility than mailing list posts, and it's a good place to collect information all in one place. I'm curious: what base address did you use when you changed it? > If the fix for the memory rebasing issue ends up being that > OpenSSL needs to be configured with a different base address, that > would be good to include in the build documentation for tcnative. > The file \jni\native\srclib\BUILDING would be a good place for such > a note. But, if the interfering Tomcat piece were to be found and > resolved, you wouldn't need it. I suspect this is an OS-related thing that Tomcat can't really affect. Note that (other than tcnative and the win32 service-launcher), Tomcat doesn't have any native code at all, so it can't really affect this kind of stuff. Tomcat just issues a System.loadLibrary() call and lets the JVM and OS take over. >>> With my test application, the original base address was not >>> being changed by the OS, according to process explorer, which >>> is why it worked with the original build. >>> >>> Thanks for your help! >> >> No problem. If there were any other gotchas you found when >> building tcnative/FIPS/win32 could you let us know? Actually, >> creating a Wiki page is easy to do and you could help others who >> are trying to do the same thing. > > One minor issue I found when building tcnative on Windows was that > the BUILDING file in the \jni\native directory in > tomcat-native-1.1.27-win32-src.zip appears to contain UNIX build > instructions. This probably isn't appropriate, since the zip file > is specific to win32. That's a good point. Could you log that in Bugzilla as well? There are (brief) building instructions on http://tomcat.apache.org/native-doc/ but they should probably also be in the BUILDING file. > If there's a good place to put a wiki page about this, let me > know, and I can try to add something. Really anywhere under http://wiki.apache.org/tomcat/FAQ would be great. If I were looking for information about this, I'm not sure where I'd look first. Perhaps under "Security"? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRuj2oAAoJEBzwKT+lPKRY2rYQAKbgmjzUDFF3FeoJRZ72yhFf ibtmO/7E5KFk9OOIVoDrFrIslCmfquHTeQZQHD2UrJ00OOL9tgSqbd5pyapfXjK9 LjV7BgyWu0YhiVbjDhXYpZQgzYPsUUHb1KyNhzVjqhwOJYaqhnnw6Bx5M1jc6FJb oA0WZC8ODxgMpqnBG7qrB/mDIcRr9UViv/k7ChDn4mZeHmVfTNsB9NUkNWXCXZlc HOzxA9imc7EcManaesIMqHbwTwbggR+nnsvxGn2k3aNmS1Wp5W+Svjjco1E7xK8b T44AGEyGAmywFvOF24Cm89rfMkCouat2fAdOH29myEtbHm0B27umjXaddifEvjE9 Rxf2oyW5Nb/N2ZQwBgdFMHXKdtMVGiKinqJhqVlLVr1NBarfaU8m85Kfv7tq+eIu tVezTMDzRyM3tMkhYDxRzNQ1/vlgbIFcapR+uiJSbQJVnnOl6IStYznhWja4f7t7 WF7xjPTGGlRgFy7MUwI97U/bnCD8S5PnJIjENuanoa1ebTkRfDGRgZNx6/v0Cm8H kpATMBRNEeznxdLVpC4hONjOLa/6AVvvmiA+kvfuKnDomcEKdU/ZAx88EoZt7HQv HeFWDNp8sJIB8wXq/Srn48kgfAuPOVpwHBIlS8nnNGUwjasxZtvyOkMn5oS7klEF 11YGFTZAd8SAuf8Xy8bl =SPZh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org
> > I figured out the problem. The error was due to my system rebasing the > > libeay32.dll library from its desired base address of 0xFB00000. > > According to OpenSSL documents, this is supposed to generate a > > specific error message of > > FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED, but > because I wasn't > > seeing that, I didn't think that was the problem. > > Interesting. Do you think it was being swallowed-up somewhere? Like I said, > tcnative/FIPS hasn't gotten a huge amount of exposure. I think the error message issue might be a problem with OpenSSL itself. As far as I can tell, tcnative is simply parroting back the error message that OpenSSL gives it. > Do you think there are ways it could be improved? Better error checking, > etc.? I implemented it as simply as I possibly could. The biggest problem seems to be that something in Tomcat on Windows is interfering with OpenSSL's normal base address request (0xFB00000). Normally this doesn't matter, but with the FIPS build, if the base address of the library is moved from what it expects, the result is a fingerprint error when FIPS mode is enabled. I ran the openssl utility on the same system as Tomcat, and Process Explorer shows that its copy of libeay32.dll stays at the correct address. Additionally, I tested the FIPS-compatible libeay32.dll on a different server with Tomcat, and had the same problem. This seems to indicate that the memory address issue is specific to Tomcat, not the server. I can't tell from Process Explorer why libeay32.dll is being rebased (I didn't see any other libraries under tomcat7.exe that were obviously taking up the same address space). I think it's going to take someone with more experience with both Windows and Tomcat than I to figure that one out. I suppose it might be worthy of a bug report, at least. > (I also noticed a small bug when checking the code around FIPS_mode_set in > tcnative: the OpenSSL docs say that if > FIPS_mode_set(x) is successful and x != 0, then the function returns x. The > check in there is against 1 and not x. So that could afford to be fixed.) > > > However, process explorer showed that the base address of libeay32.dll > > in the tomcat7.exe process was not at its correct base address. I > > recompiled OpenSSL with a new base address, verified that the new dll > > wasn't being rebased, and then turned on FIPS mode, and it worked. > > Wow, that could certainly confuse things. > > Again, I don't know anything about building on win32, but is that the kind of > thing that we could better-document (or document /at all/) somewhere in > the source bundle? Is there a project file that could contain such a hint that a > casual DIY user like you would have consulted? If the fix for the memory rebasing issue ends up being that OpenSSL needs to be configured with a different base address, that would be good to include in the build documentation for tcnative. The file \jni\native\srclib\BUILDING would be a good place for such a note. But, if the interfering Tomcat piece were to be found and resolved, you wouldn't need it. > > With my test application, the original base address was not being > > changed by the OS, according to process explorer, which is why it > > worked with the original build. > > > > Thanks for your help! > > No problem. If there were any other gotchas you found when building > tcnative/FIPS/win32 could you let us know? Actually, creating a Wiki page is > easy to do and you could help others who are trying to do the same thing. One minor issue I found when building tcnative on Windows was that the BUILDING file in the \jni\native directory in tomcat-native-1.1.27-win32-src.zip appears to contain UNIX build instructions. This probably isn't appropriate, since the zip file is specific to win32. If there's a good place to put a wiki page about this, let me know, and I can try to add something. --Steve Nickels Ipswitch, Inc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chuck, On 6/13/13 4:40 PM, Caldarale, Charles R wrote: >> From: Jane Muse [mailto:JMuse@rocketsoftware.com] Subject: RE: >> Class cast exception when starting tomcat 7.0.1 > >> I had catalina.jar in WEB-INF/lib. > > Very, very bad move. > >> It's needed because we have an implementation of Realm to store >> an encrypted tomcat password users enter in the webapp. > > Your custom implementation of Realm should be in Tomcat's lib > directory, not the webapp's. See: > http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#What_is_a_Realm? > > Such a Realm should not be tied into the operation of any webapp, > other than configuring the webapp to use it. > >> If I remove it and add the catalina.jar from tomcat_home/lib to >> the classpath > > Not sure what you mean by adding it to the classpath; please > explain. > >> I have to change the signature from >> org.apache.catalina.realm.RealmBase.Digest(String, String) to >> org.apache.catalina.realm.RealmBase.Digest(String, String, >> String). > > That's because internal Tomcat APIs often change between levels. > You certainly cannot count on using an older version of Realm with > a newer Tomcat (or vice versa). > >> Should I not be writing code that needs classes from >> catalina.jar? > > It would certainly be desirable not to be dependent on internal > Tomcat classes. Why do you think a Realm should be storing a > password (encrypted or not) anywhere? A Realm would normally be > reading a password from some controlled storage, not writing to > it. +1 I'm interested in what the custom realm does. Tomcat's realms all support simple hashing via MessageDigest (i.e. no salting, iteration, password-hashing algorithms, etc.) which is often enough for most people (yet I'm not one of them). If you are symmetrically-encrypting your passwords, you are setting yourself up for security problems. If you want to implement something more elaborate (say, you want to implement bcrypt password-hashing instead of MD5), then you'll have to do it yourself. I've been threatening to write-up some patches to allow pluggable password-mangling algorithms into Tomcat Realms, but I have not bothered to do so, yet. If there was more interest in such things, I might be persuaded to be a little more diligent. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRujQTAAoJEBzwKT+lPKRYwcMP/1u6A4gaWA+NpKs1UgpA8Gr/ qvYqcMt2sjRMPsHEd0uGcxa/SThGJHU351myfMNW4VLfvxV2/++nbnJUlILV3vNS 3h7N6LZrBjAc4CC4u5Xx3MMH4cIY1/jSK0Apnp0inN/zQXTOIT12IRQAT/TNRppS xxjxcIseZiiIkcsrDx4RS57EjXPNS0abEknCCWfpdldu3KTiZemXu0Loq4jZYXNv WGit1orL4MFNPEP1CYl5bxaEMfHd4QpSDLY7DG+OQn/AD+xsNuhNwuTc7QI40aLu 9xAN+ebZL1Qo/WmvVQYyMEdPvP8Xc8xSi9uuaaBSnI05I5+tCkSHaZUJZ/JxJrNk wpAxaIxVHC3YQS/PDsLowY2+MIMXCDnZWi/QOg1TiDypLn5bEGNnJWDUa9L8suYc hyMCGAh93eFIbkb/wB4hHNHp2Lzqbg31YVWvY53wEGUL1WRkvVzVTlQjQ8pR1cUz 8UyVOD1nG21KnwgelCgJKf4FWNtyxvah+52lTSP+HDieAt/+mLY4Z6PH5AUEte+2 QvaO6wfcfSfERA8vIy43XWRQXuciWmRtQypdmHeZQ4KI5ajRteyUKLIu2P1wahmT W+6VyVvDm+k7DW9p7l0XodX/ivw+XChmCm5EXZbDqrhkyelX22lv5jSxn4ROzkUg HePguW0/PF6NNBb5BFg0 =Jhko -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org