Re: [Resin-interest] Question on db based distributed session
Jacky, Whatever you quoted (in red) does not apply to your case, because in most of your situations, you did not have another Resin instance to be notified, as in it will notify the owner of the change At some point of step 2 and step 5, you did not even have any Resin instance running. But that does not mean this is not a problem. JDBC based session store should always contain the last known valid state, no matter which server was running. I noticed that your case has been filed into Resin bug http://bugs.caucho.com/view.php?id=1544 http://bugs.caucho.com/view.php?id=1544. . So, stop worrying. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jacky Sent: Monday, January 15, 2007 2:17 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Question on db based distributed session Eric? Sam? Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad Jacky wrote: Dear all, First of all, thanks for all the attentions. Greatly appreciated. Josh, - Please forgive me as i do not understand your have your cake and eat it too metaphor :S - I'm trying to implement the database backed distributed sessions as shown in http://www.caucho.com/resin-3.0/config/sessions.xtp and i dont take turn it off as a solution, at least not until i fully understand that this will not work. - You may be right with the clock of server A and server B not in sync, I'll have it checked.. Eric, - Yes, resin knows about my load balanced cluster (refer to the specific settings below) - I'm using apache with mod_caucho as the load balancer, is this inside or outside? :D - No, i'm not using always-load-session. I didnt' think that i need (but i'll give it a shot). Referring to http://www.caucho.com/resin-3.0/config/sessions.xtp, there is a paragraph stating this: For efficiency, the owning JVM keeps a cache of the session value, so it only needs to query the database when the session changes. If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware. my specific settings: #Apache snippet VirtualHost *:80 DocumentRoot /www/appA ServerName somedomain.com DirectoryIndex index.jsp ResinConfigServer 192.168.1.1 6802 ResinConfigServer 192.168.1.2 6802 CauchoStatus yes # do not remove, otherwise apache will serve the jsp source code once resin is down AddHandler caucho-request .jsp /VirtualHost # Resin snippet !-- Yes i'm aware that client-live-time and read-timeout is not supposed to be manually configured -- cluster client-live-time120s/client-live-time srun id=a host=192.168.1.1 port=6802 index=1 read-timeout=120s/ srun id=b host=192.168.1.2 port=6802 index=2 read-timeout=120s/ /cluster persistent-store type=jdbc init data-sourcejdbc/session/data-source /init /persistent-store host id=somedomain.com root-directory=/www/appA web-app id=/ document-directory=/www/appA session-config !-- 3 hour timeout -- session-timeout180/session-timeout use-persistent-store/ always-save-session/ /session-config servlet-mapping url-pattern=/servlet/* servlet-name=invoker/ /web-app /host Sam, I have 2 questions: Quote: At this point, A (the primary) will contact B to try to get any updates to the session that have been made. Since B is down, A cannot get the session from it. - Since i use always-save-session, shouldn't it try to get from B, but couldn't it get from the DB? Quote: So it has to go with the outdated session that it has, because it cannot get the updated session from B. - Please do correct me if i'm wrong, referring to this: If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware. - When B logs out my session, shouldn't it updates A's cache and the database at the same time? - Is it because i didn't use always-load-session ?? Gary Zhu, Quote: Even if server A and server B are configured to use the same database on server C, for a particular user session (say session id: abcDGs299928), server A and server B will have two different database entries of the session data, am I getting it right ? - I have thought of this as well when i look at the records in the table persistent_session of my mysql database. - But still... If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware. PS: Apache/2.0.55 Resin professional 3.0.19. Thanks all !! Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad
Re: [Resin-interest] Resin... ?????
On Jan 14, 2007, at 9:06 PM, Akila Amarathunga wrote:
Hi Knut,
JVM sets the -Xss to 1 Megabytes.. It has open 1028 files (REG) at the
time of giving the error..
At the moment my app open lots of Jar files which uses 10 mb of
space...
java27042 xxx844rREG 9,1 1189992
11814189/app-dir/WEB-INF/lib/wicket-1.2.1.jar
Am I geeting the 503 error cos of that ?
Assuming your file descriptor limit is near 1024, that's likely. Do
you know anything that might be keeping those file descriptors open?
I'm not familiar with wicket.
-- Scott
Thanks,
Akila
On Sun, 2007-01-14 at 12:13 -0800, Knut Forkalsrud wrote:
You might want to try jconsole or something to figure out if you're
running out of heap space. Depending on what your application
does 512
MBytes may not be enough. With 2GB of physical RAM on the machine
you
can probably afford to allow the JVM more memory.
When you get close to 1024 open files, try to figure out what
those file
handles represent, with a command like lsof -p 32335 | awk
'{ print $5
}' | sort | uniq -c where 32335 is the process id of the JVM.
Are they
all files (REG) or sockets (IPv4/IPv6)?
A long shot: I assume the stack size you report is from ulimit -s
which reports in kilobytes. Resin's startup script by default
sets the
-Xss switch for the JVM to limit the stack size to 1 Megabyte.
Make
sure that is the case for your installation as well, for example with
cat /proc/32335/cmdline | tr \\0 \\n | fgrep -- -Xss where 32335 is
the Resin JVM process id. Otherwise you have up to 2048 threads *
10MB/thread = 20GByte of address space. If you're on a 32 bit CPU
that
won't work. You're likely to have problems at 2GByte (the OS,
JVM, etc
want some address space too), which means about 200 simultaneous
threads.
-Knut
[EMAIL PROTECTED] wrote:
hi All,
Well I used resin for few months now ... but i'm really sorry to
say its a
bad experience. At the moment my settings are,
Server - RHEL (with 2 pros.)
RAM - 2 GB
Resin-pro-3.0.21
stack size 10240
Heap - 256 MB - 512 MB
Open files limit (ulimit -n) - 2048
Threads - 2048
If the number of files open by resin exceeds (used lsof) 1024,
apache
gives 503 server down for maintenance error.
Please tell me what I'm doing wrong here..?
Regards,
Akila
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin... ?????
I would guess heap space is your problem. Have you made absolutely sure
you're not running out of heap space?
-Knut
Akila Amarathunga wrote:
Hi Knut,
JVM sets the -Xss to 1 Megabytes.. It has open 1028 files (REG) at the
time of giving the error..
At the moment my app open lots of Jar files which uses 10 mb of
space...
java27042 xxx844rREG 9,1 1189992
11814189/app-dir/WEB-INF/lib/wicket-1.2.1.jar
Am I geeting the 503 error cos of that ?
Thanks,
Akila
On Sun, 2007-01-14 at 12:13 -0800, Knut Forkalsrud wrote:
You might want to try jconsole or something to figure out if you're
running out of heap space. Depending on what your application does 512
MBytes may not be enough. With 2GB of physical RAM on the machine you
can probably afford to allow the JVM more memory.
When you get close to 1024 open files, try to figure out what those file
handles represent, with a command like lsof -p 32335 | awk '{ print $5
}' | sort | uniq -c where 32335 is the process id of the JVM. Are they
all files (REG) or sockets (IPv4/IPv6)?
A long shot: I assume the stack size you report is from ulimit -s
which reports in kilobytes. Resin's startup script by default sets the
-Xss switch for the JVM to limit the stack size to 1 Megabyte. Make
sure that is the case for your installation as well, for example with
cat /proc/32335/cmdline | tr \\0 \\n | fgrep -- -Xss where 32335 is
the Resin JVM process id. Otherwise you have up to 2048 threads *
10MB/thread = 20GByte of address space. If you're on a 32 bit CPU that
won't work. You're likely to have problems at 2GByte (the OS, JVM, etc
want some address space too), which means about 200 simultaneous threads.
-Knut
[EMAIL PROTECTED] wrote:
hi All,
Well I used resin for few months now ... but i'm really sorry to say its a
bad experience. At the moment my settings are,
Server - RHEL (with 2 pros.)
RAM - 2 GB
Resin-pro-3.0.21
stack size 10240
Heap - 256 MB - 512 MB
Open files limit (ulimit -n) - 2048
Threads - 2048
If the number of files open by resin exceeds (used lsof) 1024, apache
gives 503 server down for maintenance error.
Please tell me what I'm doing wrong here..?
Regards,
Akila
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question on db based distributed session
Gary, thanks for the reply. Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad Gary Zhu wrote: Jacky, Whatever you quoted (in red) does not apply to your case, because in most of your situations, you did not have another Resin instance to be notified, as in "it will notify the owner of the change" At some point of step 2 and step 5, you did not even have any Resin instance running. But that does not mean this is not a problem. JDBC based session store should always contain the last known valid state, no matter which server was running. I noticed that your case has been filed into Resin bug http://bugs.caucho.com/view.php?id=1544. So, stop worrying. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jacky Sent: Monday, January 15, 2007 2:17 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Question on db based distributed session Eric? Sam? Warm regards, Jacky Wong Software Engineer Qinetics Solution Berhad Jacky wrote: Dear all, First of all, thanks for all the attentions. Greatly appreciated. Josh, - Please forgive me as i do not understand your "have your cake and eat it too" metaphor :S - I'm trying to implement the database backed distributed sessions as shown in http://www.caucho.com/resin-3.0/config/sessions.xtp and i dont take "turn it off" as a solution, at least not until i fully understand that this will not work. - You may be right with the clock of server A and server B not in sync, I'll have it checked.. Eric, - Yes, resin knows about my load balanced cluster (refer to the specific settings below) - I'm using apache with mod_caucho as the load balancer, is this inside or outside? :D - No, i'm not using always-load-session. I didnt' think that i need (but i'll give it a shot). Referring to http://www.caucho.com/resin-3.0/config/sessions.xtp, there is a paragraph stating this: "For efficiency, the owning JVM keeps a cache of the session value, so it only needs to query the database when the session changes. If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware." my specific settings: #Apache snippet VirtualHost *:80 DocumentRoot /www/appA ServerName somedomain.com DirectoryIndex index.jsp ResinConfigServer 192.168.1.1 6802 ResinConfigServer 192.168.1.2 6802 CauchoStatus yes # do not remove, otherwise apache will serve the jsp source code once resin is down AddHandler caucho-request .jsp /VirtualHost # Resin snippet !-- Yes i'm aware that client-live-time and read-timeout is not supposed to be manually configured -- cluster client-live-time120s/client-live-time srun id="a" host="192.168.1.1" port="6802" index="1" read-timeout="120s"/ srun id="b" host="192.168.1.2" port="6802" index="2" read-timeout="120s"/ /cluster persistent-store type="jdbc" init data-sourcejdbc/session/data-source /init /persistent-store host id="somedomain.com" root-directory="/www/appA" web-app id="/" document-directory="/www/appA" session-config !-- 3 hour timeout -- session-timeout180/session-timeout use-persistent-store/ always-save-session/ /session-config servlet-mapping url-pattern="/servlet/*" servlet-name="invoker"/ /web-app /host Sam, I have 2 questions: Quote: At this point, A (the primary) will contact B to try to get any updates to the session that have been made. Since B is down, A cannot get the session from it. - Since i use always-save-session, shouldn't it try to get from B, but couldn't it get from the DB? Quote: So it has to go with the outdated session that it has, because it cannot get the updated session from B. - Please do correct me if i'm wrong, referring to this: "If another JVM stores a new session value, it will notify the owner of the change so the owner can update its cache. Because of this notification, the database store is cluster-aware." - When B logs out my session, shouldn't it updates A's cache and the database at the same time? - Is it because i didn't use always-load-session ?? Gary Zhu, Quote: Even if server A and server B are configured to use the same database on server C, for a particular user session (say session id: abcDGs299928), server A and server B will have two different database entries of the session data, am I getting it right ? - I have thought of this as well when i look at the records in the table persistent_session of my mysql database. - But still... "If another JVM stores a new session value, it will notify the owner of the change so the owner
