Share info across different sessions servers
Hello: I need to share data between sessions running in different Tomcat server. I 'd been thinking about using a JMS broker (as ActiveMQ ): - when a new session is created in Tomcat A, it's created a new unique topic for this session - the session registers itself as listener of that topic ( the only one listener ) - publish the name of this topic by some way , so it can be found by another session in Tomcat B I don't know if somebody has used something like this sometime, and how he/she did it Any suggestion/opinion ? I'm not sure either use only one topic for all session created or one topic per session ? I think that one topic per session is more safe because if I use one topic for all sessions, if one message is not read quickly by one consumer ( a session ), could block the topic, Obviously , i'll define a TTL for messages/topic Thanks and regards
Re: Share info across different sessions servers
Hi! What kind of data do you want to share? Just a view bytes? Is there an requirement concerning durability/persistence/performance? Is this user=session related or do you want to share data in general? Usually if you have a session id the lb will route your user always to the same container? What about session replication, a database, terracotta? JMS: i doubt this will be working... you need a persistent message or a container started after the change was send will not noticed about it... Jens Sent from my iPhone On 02.07.2013, at 08:45, Jose María Zaragoza demablo...@gmail.com wrote: Hello: I need to share data between sessions running in different Tomcat server. I 'd been thinking about using a JMS broker (as ActiveMQ ): - when a new session is created in Tomcat A, it's created a new unique topic for this session - the session registers itself as listener of that topic ( the only one listener ) - publish the name of this topic by some way , so it can be found by another session in Tomcat B I don't know if somebody has used something like this sometime, and how he/she did it Any suggestion/opinion ? I'm not sure either use only one topic for all session created or one topic per session ? I think that one topic per session is more safe because if I use one topic for all sessions, if one message is not read quickly by one consumer ( a session ), could block the topic, Obviously , i'll define a TTL for messages/topic Thanks and regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Share info across different sessions servers
Thanks I need to share formatted text data ( XML, key/value, ...I'm not sure yet ) I don't understand your comment about JMS . I will use a JMS broker as ActiveMQ . Probably it will be embebbed into the same JVM than Tomcat server. ActiveMQ supports persistent messages I could use a database but I don't want to be making polling every X seconds by a session Regards 2013/7/2 mailingl...@j-b-s.de mailingl...@j-b-s.de Hi! What kind of data do you want to share? Just a view bytes? Is there an requirement concerning durability/persistence/performance? Is this user=session related or do you want to share data in general? Usually if you have a session id the lb will route your user always to the same container? What about session replication, a database, terracotta? JMS: i doubt this will be working... you need a persistent message or a container started after the change was send will not noticed about it... Jens Sent from my iPhone On 02.07.2013, at 08:45, Jose María Zaragoza demablo...@gmail.com wrote: Hello: I need to share data between sessions running in different Tomcat server. I 'd been thinking about using a JMS broker (as ActiveMQ ): - when a new session is created in Tomcat A, it's created a new unique topic for this session - the session registers itself as listener of that topic ( the only one listener ) - publish the name of this topic by some way , so it can be found by another session in Tomcat B I don't know if somebody has used something like this sometime, and how he/she did it Any suggestion/opinion ? I'm not sure either use only one topic for all session created or one topic per session ? I think that one topic per session is more safe because if I use one topic for all sessions, if one message is not read quickly by one consumer ( a session ), could block the topic, Obviously , i'll define a TTL for messages/topic Thanks and regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help with crossContext=true and getRequestDispatcher()
On 02/07/2013 03:28, Paul Hammant wrote: Hi Mark, thanks for the reply. I've modified https://github.com/paul-hammant/servletDispatcherTest to include scripts to reproduce the problem, and to show the two web-apps working separately, but not in the getRequestDispatcher(..).include(..) way. The scripts download an anointed version of Tomcat7, add the crossContext=true attr to context.xml, and even copy the war files into the webapps/ folder. In the README.md, which Github kindly renders into HTML on the front page of the project, there's instructions to build/deploy, as well as what URLs to click on to see the problem, as I see it. There are now three servlet-filters activated for different urls: /a/IOutputMyThreadID (class of same name) /a/AIncludingContentFromB (class of same name, extends IOutputMyThreadID) /b/IAlsoOutputMyThreadID (class of same name) There is no Tomcat bug here. The bug is in the test case. Since the test is for Tomcat 7, see the following sections of the Servlet 3.0 specification for an explanation: - section 6.2.5 - section 9.1 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: BackupManager start fails under heavy load
2013/6/28 Patrick Savage patrick.sav...@3pillarglobal.com We have an issue in our Tomcat 7.0.30 clustered production environment on RHEL 5 where Tomcat fails to start our application when other nodes in the cluster are under extremely heavy load. It fails because the BackupManager cannot start the replicated map due to timeouts trying to connect to all the other nodes. The only way to recover from this seems to be shutting down almost all of the nodes and then starting them again. The cluster has 9 nodes, but we have also had the problem with 6 nodes. Is there a way to ensure the application will start even if the BackupManager cannot connect to the other nodes? No. If replication map fails to start, associated context will fail to start. I will implement a feature to ensure the application will start even If replication map fails to start. -- Keiichi.Fujino
Re: Help with crossContext=true and getRequestDispatcher()
Thanks Mark. The crucial piece that I missed was the filter-mapping for the to-be-included thing had to have dispatcherINCLUDE/dispatcher Now that it's all working, I updated the Github repo to be a demonstration of it all working, rather than a problem definition. - Paul On Tue, Jul 2, 2013 at 2:42 AM, Mark Thomas ma...@apache.org wrote: On 02/07/2013 03:28, Paul Hammant wrote: Hi Mark, thanks for the reply. I've modified https://github.com/paul-hammant/servletDispatcherTest to include scripts to reproduce the problem, and to show the two web-apps working separately, but not in the getRequestDispatcher(..).include(..) way. The scripts download an anointed version of Tomcat7, add the crossContext=true attr to context.xml, and even copy the war files into the webapps/ folder. In the README.md, which Github kindly renders into HTML on the front page of the project, there's instructions to build/deploy, as well as what URLs to click on to see the problem, as I see it. There are now three servlet-filters activated for different urls: /a/IOutputMyThreadID (class of same name) /a/AIncludingContentFromB (class of same name, extends IOutputMyThreadID) /b/IAlsoOutputMyThreadID (class of same name) There is no Tomcat bug here. The bug is in the test case. Since the test is for Tomcat 7, see the following sections of the Servlet 3.0 specification for an explanation: - section 6.2.5 - section 9.1 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials
Greetings, On Wed, Jun 26, 2013 at 4:08 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, But, even when sending UTF-8 encoded data according to this principle, they are *not* indicating that it is UTF-8 data, which is basically wrong, because the standard HTTP/HTML character set is iso-8859-1, and they *should* indicate it when that is not what they are sending. But that is the reality. No, as much as it pains me to do so, I agree with with Mozilla folks on this one: adding a charset attribute to an application/x-form-urlencoded Content-Type violates the spec. There is no good solution. ... We really need an RFC for HTTP 2.0, with UTF-8 as the default charset/encoding. +1 Maybe they can clear-up Tomcat logging configuration while they are at it :) Thank you! This discussion was quite informational. -Shanti
Monitoring Tomcat - In-depth details
All, For lack of funds initially and now for a stalemate in the project, we do not have a JVM monitoring tool yet. JavaMelody was recently discussed. I like the fact that there is a dashboard and history of metrics. In looking at it, I find JavaMelody lacking in in-depth diagnostics of the JVM. Top-N SQL statements, Transaction Tracing, metrics co-relation, call-back tree, thresholds and alerting are a few. Are there are any OpenSource projects that instrument the JVM at byte-code and provide detailed metrics more than what JMX offers? Or am I missing something with JavaMelody? Thanks! -Shanti
Re: [slightly OT] FORM based authentication and utf-8 encoding of credentials
Shanti Suresh wrote: Greetings, On Wed, Jun 26, 2013 at 4:08 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, But, even when sending UTF-8 encoded data according to this principle, they are *not* indicating that it is UTF-8 data, which is basically wrong, because the standard HTTP/HTML character set is iso-8859-1, and they *should* indicate it when that is not what they are sending. But that is the reality. No, as much as it pains me to do so, I agree with with Mozilla folks on this one: adding a charset attribute to an application/x-form-urlencoded Content-Type violates the spec. There is no good solution. ... We really need an RFC for HTTP 2.0, with UTF-8 as the default charset/encoding. +1 Maybe they can clear-up Tomcat logging configuration while they are at it :) Thank you! This discussion was quite informational. You are welcome. Further as relatively [OT], in some other - non-Tomcat, non-Java - applications, we solve the general issue as follows (taking into account the deficiencies of the RFCs, the servers, the browsers, and the users) : - when programmers create the html documents containing the forms, they must make sure that they use a tool which really saves the html document in the charset/encoding that corresponds to their wishes - the html page should contain a declaration like : meta http-equiv=Content-Type content=text/html; charset=x / (where is the correct charset/encoding, like UTF-8) - each form that is sent to the browser is sent by the server with an explicit HTTP header : Content-type: text/html; charset= (that normally happens automatically, but you should nevertheless check that it matches) - the form tag of the form should contain the accept-charset attribute with the expected character set as value, like form accept-charset=UTF-8 ... - the form itself contains a hidden parameter like : input type=hidden name=charset-test value=y (where y is a character sequence which is so that, seen as bytes, its length would be different depending on the real character set used. E.g., for Europe, ÖöÜüÄä) - the application which receives the form submit data, must first check if the string received for the charset-test parameter matches its expectations. In other words, if the application expects UTF-8, then it should check that the received string has a byte length of 12 and a character length of 6, and matches a Unicode string ÖöÜüÄä) And if it doesn't, then it should take appropriate action (abort the action, or try another charset) (if the form sent by the server contains additional data coming from a back-end database system, then one should also check that the charset of that data matches the one of the form of course). This may look a bit like overkill, but it is the result of long and painful real-world experience with multi-lingual applications used with multiple browsers and multiple types of users in multiple countries doing cut-and-paste of all kinds of stuff into forms. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
I'm testing out the parallel deployment process for my company and am seeing a difference in how user migrations to the new version of the application occur based upon how you deploy your application. Our configuration involves many different web sites that all point to the same folder. Some example context configuration files are provided below to help illustrate what I mean: Website1.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp/Context Website2.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp/Context Website3.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp/Context Yesterday some individuals from this mailing list helped me understand that if I create a new context file with ##001 appended at the end then that will allow me to deploy a new version of the application. For example: Website1##002.xml Context reloadable=true crossContext=true sessionCookiePath=/ docBase=/Users/jeremy/tomcat/manualDeploy/myapp-v2/Context When I run Jmeter requests consistently against website1 and then deploy the new version of the web site (website1##002) I do not see any active sessions for website##002 in tomcat manager even after website1##002 is fully loaded. Please note that if I open up a new safari browser window and access website1#002 then I do see an active session. What is confusing me at this point is that if I deploy a WAR using the auto deployment method (copying the myapp.war into the webapps folder) and then deploy a new version using the same mechanism (myapp##002.war) then I do see the users automatically migrated to the new version when running my Jmeter tests. Please note that this behavior (immediate migration) is what we desire. In addition to the fact that when the migration of users occurs is different, I am also seeing a huge discrepancy between the number of sessions that tomcat manager says are currently active when I deploy using the folder approach vs. the automatic deployment approach. When using the folder approach the number of sessions always matches the number of users (via a thread group) in Jmeter. However, when I use the automatic deployment process the number of sessions continues to grow as I allow Jmeter to run longer (at one point I had thousands of sessions). Can anyone explain why I'm seeing a difference in the behavior between the two deployment mechanisms and if so, how would I mimic what is happening in regards to the automatic migration of users to new versions while using the folder deployment approach. Thank you very much for your assistance, Jeremy
Re: Monitoring Tomcat - In-depth details
Hello, check http://www.moskito.org out. MoSKito is an open source project that has been around since 2007. It supports most of the things you mentioned except byte-code instruction yet (an agent is currently in development, but its not that easy to implement ;-)). But you can integrate it along spring-bean, cdi-beans with decorators, filters, java proxies etc pp. Check https://confluence.opensource.anotheria.net/display/MSK/Integration+Guidefor details. regards Leon P.S. Feel free to ask directly or on moskito mailing list for support. On Tue, Jul 2, 2013 at 4:11 PM, Shanti Suresh sha...@umich.edu wrote: All, For lack of funds initially and now for a stalemate in the project, we do not have a JVM monitoring tool yet. JavaMelody was recently discussed. I like the fact that there is a dashboard and history of metrics. In looking at it, I find JavaMelody lacking in in-depth diagnostics of the JVM. Top-N SQL statements, Transaction Tracing, metrics co-relation, call-back tree, thresholds and alerting are a few. Are there are any OpenSource projects that instrument the JVM at byte-code and provide detailed metrics more than what JMX offers? Or am I missing something with JavaMelody? Thanks! -Shanti
Re: Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeremy, On 7/2/13 12:09 PM, Majors, Jeremy wrote: When I run Jmeter requests consistently against website1 and then deploy the new version of the web site (website1##002) I do not see any active sessions for website##002 in tomcat manager even after website1##002 is fully loaded. Please note that if I open up a new safari browser window and access website1#002 then I do see an active session. Are you sure that JMeter is creating new users during its test? Usually JMeter is configured to execute a workflow and preserve cookies, just as a real user with a browser would. So, if you have 100 users running your test(s) indefinitely, you'll only get 100 sessions no matter what. If they all are created before you deploy your new webapp version, then those sessions will remain attached to the old version (that's how parallel deployment works). What is confusing me at this point is that if I deploy a WAR using the auto deployment method (copying the myapp.war into the webapps folder) and then deploy a new version using the same mechanism (myapp##002.war) then I do see the users automatically migrated to the new version when running my Jmeter tests. Please note that this behavior (immediate migration) is what we desire. I think you need to look carefully at what is really happening. It's not clear from above how you are triggering a parallel deployment in each case. It basically sound like you are saying while it does not work, it actually does. Please be clear about what you are doing when you think it works and what you are doing when you think it doesn't work. Also tell us what you expect and why, and what happens instead. In addition to the fact that when the migration of users occurs is different, I am also seeing a huge discrepancy between the number of sessions that tomcat manager says are currently active when I deploy using the folder approach vs. the automatic deployment approach. When using the folder approach the number of sessions always matches the number of users (via a thread group) in Jmeter. However, when I use the automatic deployment process the number of sessions continues to grow as I allow Jmeter to run longer (at one point I had thousands of sessions). Do your JMeter users ever log out? - -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/ iQIcBAEBCAAGBQJR0yWbAAoJEBzwKT+lPKRY4y8QAJ9d9Rfth362CgMpvKaT/zQH LMvUBr4jJT5YjkwKhK3qXXzOHuJRvBtFZy4ul/4TERR8p8fUChnVTTTVWPPdfw2f TbXiVjGpgVyveRMWRQSGHukHSelUvN9SkkEfxkD5x6oZj4lWTNsZ4mTUgmOYAwsG z6xchc6CJF1Cay9mE/vgzhYQrbYH/A2XuH7BlSWqH6JzMz1r+BrOpiIETwCnr0bv sdUQPwFIT3EEjz+rKBwcseVQ2arsEsJ+iI9RCVVy31AF0Eno1oWxm6OLSEHTDs68 MLUj9rNULv8ZogJ9XPLlqowwCr8ve3e8DmhLzG4Ye4j+OnJlx/87CQnv8XFNqH9I IpWw4mQYGoYXw4mDhQT7P3NRhLzuaA14RVI2vkj2DPY7qj9Oj47YRfAF5gjZjNTK lq5etTiG4TiwzvzadvsXpz/zzIUG/RQ489DeDLlkT/7PwKaohwG5xIHPC+JK/+Xd FjbkW92fYy6g2w+GA3L3mUZmeWI1XX0EyS6vIX9MPmOmkNGrKLLfc9uS3ArDMAh2 h9rTt3t+ahun0RcTDEtxQYeMDXWVgZ+eyTzvxGpkHE/Q64n/U+lcuh9P+lOsuH0c +1fCbCveQOB9h5L0Oqbc5Ha+e19VmdtkkpMP4VwV0YljoSsO7Zrmpj9F79CE+wSW twskY9X1dH+qzoPyP0+v =MPUQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Share info across different sessions servers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jose, On 7/2/13 3:22 AM, Jose María Zaragoza wrote: Thanks I need to share formatted text data ( XML, key/value, ...I'm not sure yet ) I don't understand your comment about JMS . I will use a JMS broker as ActiveMQ . Probably it will be embebbed into the same JVM than Tomcat server. ActiveMQ supports persistent messages While JMS may work, it's really not the right solution. JMS is a messaging service, and you want a data-storage service. I could use a database but I don't want to be making polling every X seconds by a session You don't have to pull any data that the user doesn't need, do you? If you don't want to use a RDBMS, how about something like memcached? I asked about using memcached a while back on this list and got some other suggestions as well (as memcached doesn't make a great fail-safe shared-data storage system... it's really meant to be more of a cache of data available elsewhere). - -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/ iQIcBAEBCAAGBQJR0ycOAAoJEBzwKT+lPKRYaAsP+wfhqoLQWwJoYLpur0Z5VOeJ GUmylaW+kllpcbdFdVG81691rjUW1Ph5yQ2MQzPFKv0bCp2cyHMWQuJgAp1rq/Lo T6Bpba6IHeyucxEAk0XZfGu4efS+wc39ncq9C3GPamEvrN+locYGtM/lqSpkSxKz 5ADXD9o2//U5Nk00N0KHPH4xsp/wtx0NJgT1p9f1VUKgU9pVvGFhHvrozvdAEcnv 9U7IQroNO7uR3RnKL/rq9CH3MsxL/gbWCWEZ21WkaguLFysc67naaSQvimIoLok9 eUfCK6Z5Bll4VeefK6YlA6E49sj01NZD1zuj0J/DGUiwBuFiNSZc1Z2NOZlue7Oo efpaRkjINouIfyk3RONa8/ZuNWf80ImX5vvJKEYK7ujc2LB7G8+ID95Toeej0eyg cZWHZo3N67nYgker4Kp4xn4VXBs4QfDzY/uOfsUyp8voNcCz6lBo38w8T3jvVJzV ci18cbWdRXQ3NrlaBkI8qJeEzMWAegM7C1IqJUspmlDHvsUIiamGA+ZF6nBNPr16 w3lx8X8xWjGM63OQaoYMbTc2ZXFCkP0zkXXEcx49zyGMSEDSk2NySw2HkAOh9iVx tr7YCDChtFg8mBQPY6CiiasEtn8j9JMK/XawdDI34LTsO1molB5OvJDGo558BqMm 3hK/JZGxPkEPapvOfWRM =tOMh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Share info across different sessions servers
Thanks Christopher : Maybe I explained myself badly I really need to send messages to a specific web session , not share data I need to pass some data ( message ) to a specific session from a remote system ( a remote process from a remote system). Finally, this data is passed to client's browser by AJAX Reverse My idea is the session creates a dynamic Queue and it configures itself as Consumer If I pass the Queue to remote process ( in message.replyTo() ) , the remote process can send data to that specific session I could use a RDBS but , in this case, session needs to create a thread to polling on a share table. And I don't like this idea, sorry. memcached sounds good but I don't know anything about it and I don't know is is based on a event-driven architecture I need 1) send data/message from a remote process to a specific web session 2) execute some code in this session 3) consume ( a.k.a, delete ) that message Persistence is not a requirement but ActiveMQ allows it I'l try it with ActiveMQ Thanks again and regards 2013/7/2 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jose, On 7/2/13 3:22 AM, Jose María Zaragoza wrote: Thanks I need to share formatted text data ( XML, key/value, ...I'm not sure yet ) I don't understand your comment about JMS . I will use a JMS broker as ActiveMQ . Probably it will be embebbed into the same JVM than Tomcat server. ActiveMQ supports persistent messages While JMS may work, it's really not the right solution. JMS is a messaging service, and you want a data-storage service. I could use a database but I don't want to be making polling every X seconds by a session You don't have to pull any data that the user doesn't need, do you? If you don't want to use a RDBMS, how about something like memcached? I asked about using memcached a while back on this list and got some other suggestions as well (as memcached doesn't make a great fail-safe shared-data storage system... it's really meant to be more of a cache of data available elsewhere). - -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/ iQIcBAEBCAAGBQJR0ycOAAoJEBzwKT+lPKRYaAsP+wfhqoLQWwJoYLpur0Z5VOeJ GUmylaW+kllpcbdFdVG81691rjUW1Ph5yQ2MQzPFKv0bCp2cyHMWQuJgAp1rq/Lo T6Bpba6IHeyucxEAk0XZfGu4efS+wc39ncq9C3GPamEvrN+locYGtM/lqSpkSxKz 5ADXD9o2//U5Nk00N0KHPH4xsp/wtx0NJgT1p9f1VUKgU9pVvGFhHvrozvdAEcnv 9U7IQroNO7uR3RnKL/rq9CH3MsxL/gbWCWEZ21WkaguLFysc67naaSQvimIoLok9 eUfCK6Z5Bll4VeefK6YlA6E49sj01NZD1zuj0J/DGUiwBuFiNSZc1Z2NOZlue7Oo efpaRkjINouIfyk3RONa8/ZuNWf80ImX5vvJKEYK7ujc2LB7G8+ID95Toeej0eyg cZWHZo3N67nYgker4Kp4xn4VXBs4QfDzY/uOfsUyp8voNcCz6lBo38w8T3jvVJzV ci18cbWdRXQ3NrlaBkI8qJeEzMWAegM7C1IqJUspmlDHvsUIiamGA+ZF6nBNPr16 w3lx8X8xWjGM63OQaoYMbTc2ZXFCkP0zkXXEcx49zyGMSEDSk2NySw2HkAOh9iVx tr7YCDChtFg8mBQPY6CiiasEtn8j9JMK/XawdDI34LTsO1molB5OvJDGo558BqMm 3hK/JZGxPkEPapvOfWRM =tOMh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.27 on Mac OSX Lion - User Migration to New Version of Application Not Occuring
Sorry for the miscommunication. I understand that active users with a session are supposed to stay with the original version that they were associated with. My confusion was caused by the fact that when I did an auto deploy, the users were immediately being migrated to the new version of the application. I would not have expected this because I thought that the cookies attribute is set to true by default and thus they would have an active session. However, I have been able to achieve my desired results by setting cookies=false within the context files for the applications I manually deployed. Thanks, Jeremy On 7/2/13 2:10 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeremy, On 7/2/13 12:09 PM, Majors, Jeremy wrote: When I run Jmeter requests consistently against website1 and then deploy the new version of the web site (website1##002) I do not see any active sessions for website##002 in tomcat manager even after website1##002 is fully loaded. Please note that if I open up a new safari browser window and access website1#002 then I do see an active session. Are you sure that JMeter is creating new users during its test? Usually JMeter is configured to execute a workflow and preserve cookies, just as a real user with a browser would. So, if you have 100 users running your test(s) indefinitely, you'll only get 100 sessions no matter what. If they all are created before you deploy your new webapp version, then those sessions will remain attached to the old version (that's how parallel deployment works). What is confusing me at this point is that if I deploy a WAR using the auto deployment method (copying the myapp.war into the webapps folder) and then deploy a new version using the same mechanism (myapp##002.war) then I do see the users automatically migrated to the new version when running my Jmeter tests. Please note that this behavior (immediate migration) is what we desire. I think you need to look carefully at what is really happening. It's not clear from above how you are triggering a parallel deployment in each case. It basically sound like you are saying while it does not work, it actually does. Please be clear about what you are doing when you think it works and what you are doing when you think it doesn't work. Also tell us what you expect and why, and what happens instead. In addition to the fact that when the migration of users occurs is different, I am also seeing a huge discrepancy between the number of sessions that tomcat manager says are currently active when I deploy using the folder approach vs. the automatic deployment approach. When using the folder approach the number of sessions always matches the number of users (via a thread group) in Jmeter. However, when I use the automatic deployment process the number of sessions continues to grow as I allow Jmeter to run longer (at one point I had thousands of sessions). Do your JMeter users ever log out? - -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/ iQIcBAEBCAAGBQJR0yWbAAoJEBzwKT+lPKRY4y8QAJ9d9Rfth362CgMpvKaT/zQH LMvUBr4jJT5YjkwKhK3qXXzOHuJRvBtFZy4ul/4TERR8p8fUChnVTTTVWPPdfw2f TbXiVjGpgVyveRMWRQSGHukHSelUvN9SkkEfxkD5x6oZj4lWTNsZ4mTUgmOYAwsG z6xchc6CJF1Cay9mE/vgzhYQrbYH/A2XuH7BlSWqH6JzMz1r+BrOpiIETwCnr0bv sdUQPwFIT3EEjz+rKBwcseVQ2arsEsJ+iI9RCVVy31AF0Eno1oWxm6OLSEHTDs68 MLUj9rNULv8ZogJ9XPLlqowwCr8ve3e8DmhLzG4Ye4j+OnJlx/87CQnv8XFNqH9I IpWw4mQYGoYXw4mDhQT7P3NRhLzuaA14RVI2vkj2DPY7qj9Oj47YRfAF5gjZjNTK lq5etTiG4TiwzvzadvsXpz/zzIUG/RQ489DeDLlkT/7PwKaohwG5xIHPC+JK/+Xd FjbkW92fYy6g2w+GA3L3mUZmeWI1XX0EyS6vIX9MPmOmkNGrKLLfc9uS3ArDMAh2 h9rTt3t+ahun0RcTDEtxQYeMDXWVgZ+eyTzvxGpkHE/Q64n/U+lcuh9P+lOsuH0c +1fCbCveQOB9h5L0Oqbc5Ha+e19VmdtkkpMP4VwV0YljoSsO7Zrmpj9F79CE+wSW twskY9X1dH+qzoPyP0+v =MPUQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Embedded runtime in Uber jar
Hi All, I've easily enabled Tomcat 7.0.41 for our testing frameworks in our REST project. Now I'm trying to embed it in our standalone, and I'm not having an easy time of it. Below is an outline of how our uber jar is distributed. standalone apache-cassandra - usergrid-rest Our standalone depends on both apache cassandra, and the web application. We had previously pre-compiled our jsps, and included the jsp jar, as well as the compiled servlets. This has caused some issues for us, so I'd like to embed the webapp directly. This way, it will load and behave the same as when it's deployed as a web application. I've found this plugin, but it won't work for us. We also need to boostrap cassandra and it's keyspaces before starting the tomcat plugin. Ultimately we want our users to be able to launch the standalone with the java -jar command. java -jar usergrid-standalone-0.0.27.jar Any thoughts on how to accomplish this? In it's current form, I don't have an extracted webapp I can create the context from. I'm not sure how to proceed. We're already using a custom classloader to ensure that everything in our uber jar is loaded. Below is the source. Any help is greatly appreciated! https://github.com/apigee/usergrid-stack/blob/USERGRID-1731/standalone/src/main/java/org/usergrid/standalone/Server.java#L147 Thanks, Todd
Re: Share info across different sessions servers
I have am using tribes messaging to send messages between remote applications which include tomcat embedded. You construct your message and submit to a sendMessage process. All running apps are always listening for messages. They receive the message and then may or may not reply or broadcast as a result. On Wed, Jul 3, 2013 at 7:43 AM, Jose María Zaragoza demablo...@gmail.comwrote: Thanks Christopher : Maybe I explained myself badly I really need to send messages to a specific web session , not share data I need to pass some data ( message ) to a specific session from a remote system ( a remote process from a remote system). Finally, this data is passed to client's browser by AJAX Reverse My idea is the session creates a dynamic Queue and it configures itself as Consumer If I pass the Queue to remote process ( in message.replyTo() ) , the remote process can send data to that specific session I could use a RDBS but , in this case, session needs to create a thread to polling on a share table. And I don't like this idea, sorry. memcached sounds good but I don't know anything about it and I don't know is is based on a event-driven architecture I need 1) send data/message from a remote process to a specific web session 2) execute some code in this session 3) consume ( a.k.a, delete ) that message Persistence is not a requirement but ActiveMQ allows it I'l try it with ActiveMQ Thanks again and regards 2013/7/2 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jose, On 7/2/13 3:22 AM, Jose María Zaragoza wrote: Thanks I need to share formatted text data ( XML, key/value, ...I'm not sure yet ) I don't understand your comment about JMS . I will use a JMS broker as ActiveMQ . Probably it will be embebbed into the same JVM than Tomcat server. ActiveMQ supports persistent messages While JMS may work, it's really not the right solution. JMS is a messaging service, and you want a data-storage service. I could use a database but I don't want to be making polling every X seconds by a session You don't have to pull any data that the user doesn't need, do you? If you don't want to use a RDBMS, how about something like memcached? I asked about using memcached a while back on this list and got some other suggestions as well (as memcached doesn't make a great fail-safe shared-data storage system... it's really meant to be more of a cache of data available elsewhere). - -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/ iQIcBAEBCAAGBQJR0ycOAAoJEBzwKT+lPKRYaAsP+wfhqoLQWwJoYLpur0Z5VOeJ GUmylaW+kllpcbdFdVG81691rjUW1Ph5yQ2MQzPFKv0bCp2cyHMWQuJgAp1rq/Lo T6Bpba6IHeyucxEAk0XZfGu4efS+wc39ncq9C3GPamEvrN+locYGtM/lqSpkSxKz 5ADXD9o2//U5Nk00N0KHPH4xsp/wtx0NJgT1p9f1VUKgU9pVvGFhHvrozvdAEcnv 9U7IQroNO7uR3RnKL/rq9CH3MsxL/gbWCWEZ21WkaguLFysc67naaSQvimIoLok9 eUfCK6Z5Bll4VeefK6YlA6E49sj01NZD1zuj0J/DGUiwBuFiNSZc1Z2NOZlue7Oo efpaRkjINouIfyk3RONa8/ZuNWf80ImX5vvJKEYK7ujc2LB7G8+ID95Toeej0eyg cZWHZo3N67nYgker4Kp4xn4VXBs4QfDzY/uOfsUyp8voNcCz6lBo38w8T3jvVJzV ci18cbWdRXQ3NrlaBkI8qJeEzMWAegM7C1IqJUspmlDHvsUIiamGA+ZF6nBNPr16 w3lx8X8xWjGM63OQaoYMbTc2ZXFCkP0zkXXEcx49zyGMSEDSk2NySw2HkAOh9iVx tr7YCDChtFg8mBQPY6CiiasEtn8j9JMK/XawdDI34LTsO1molB5OvJDGo558BqMm 3hK/JZGxPkEPapvOfWRM =tOMh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Vince Stewart
