[Resin-interest] Resin cluster session performance problems
Hi list, I've posted before with regards to problems with clustered sessions, but I've had session-db related outages on two production servers within half-an-hour of each other. I'm running Resin 3.1.8 with a clustered persistent session configuration. I took a stacktrace when both servers stopped responding and analysed then with TDA. What I found was many threads waiting on the internal Resin database, like this: hmux-10.1.1.102:6800-10944$21858188 daemon prio=10 tid=0x5bc17800 nid=0x7a9b waiting for monitor entry [0x59f7c000..0x59f7d120] java.lang.Thread.State: BLOCKED (on object monitor) at com.caucho.db.store.Store.writeBlock(Store.java:1730) - locked 0x79f2aaa0 (a java.lang.Object) at com.caucho.db.store.Block.writeImpl(Block.java:228) at com.caucho.db.store.Block.write(Block.java:215) at com.caucho.db.store.Block.commit(Block.java:178) at com.caucho.db.store.Transaction.writeData(Transaction.java:580) at com.caucho.db.sql.QueryContext.unlock(QueryContext.java:537) at com.caucho.db.sql.UpdateQuery.execute(UpdateQuery.java:118) at com.caucho.db.jdbc.PreparedStatementImpl.execute(PreparedStatementImpl.j ava:345) at com.caucho.db.jdbc.PreparedStatementImpl.executeUpdate(PreparedStatement Impl.java:313) at com.caucho.server.cluster.FileBacking.updateAccess(FileBacking.java:353) at com.caucho.server.cluster.ClusterStore.updateAccess(ClusterStore.java:79 1) at com.caucho.server.hmux.HmuxClusterRequest.accessObject(HmuxClusterReques t.java:473) at com.caucho.server.hmux.HmuxClusterRequest.handleRequest(HmuxClusterReque st.java:215) at com.caucho.server.hmux.HmuxRequest.scanHeaders(HmuxRequest.java:655) at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:363) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682) - locked 0xaf6462c8 (a java.lang.Object) at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:730) at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:649) at java.lang.Thread.run(Thread.java:619) The session database currently stands at the 33Mb mark, which doesn't seem excessive to me. Is there anything I can do to get to the bottom of the and solve this. I'm unable to switch to database backed sessions due to issues with expired sessions not being pushed out to all nodes in the cluster (I've pressed logout but I'm still logged in - posted about this before). Any help would be greatly appreciated. rgds, Richard Richard Grantham Development --- rgrant...@limehousesoftware.co.uk Limehouse Software Ltd DDI: (020) 7566 3324 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd Bridewell Gate 9 Bridewell Place London EC4V 6AW Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Cluster sessions don't expire
Well, usually it's 60 minutes. The 60 second timeout is set when someone closes the browser without logging out (JavaScript catches the event and calls a JSP which sets the new session timeout with session.setMaxInactiveInterval(60)). This is so that if someone loses their connection to the internet they will be able to continue working without issue when it comes back (assuming it's back in under an hour). The timeout is being set by the JSP but is not acted upon. Perhaps I should explain the use case. Our application maintains a list who is logged into the system. It also allows people to lock things for editing. So that people can't lock things and go off on holiday preventing others from working we unlock anything they have locked and clear them out of the logged in list when a session is invalidated. Right now people are just closing the browser and going home and their colleagues are unable to continue the work the next day. I'd agree that half the issue is education (please press logout) but it's also something we need to be pro-active about. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 04 December 2008 17:47 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Cluster sessions don't expire On Dec 4, 2008, at 9:31 AM, Richard Grantham wrote: Yes, the logout code calls session.invalidate() and it works fine. I have some application logic in SessionListener.sessionDestroyed(...) which does some housekeeping after someone presses logout or their session times out, so it's important it's called. I'm finding that the session does not time out in the configured time (60 seconds) when, for instance, you close the browser, so SessionListener.sessionDestroyed() is not called. I assume the application is some kind of ajax connection so a 60 second timeout makes sense? We might need to do some work to add that kind of precision. Because the session timeout was designed when 30 minute timeouts were the norm, not short values, the session reaping is fairly slow. I've added a report at http://bugs.caucho.com/view.php?id=3116 -- Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 04 December 2008 16:27 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Cluster sessions don't expire On Dec 4, 2008, at 2:43 AM, Richard Grantham wrote: My woes with clustered sessions and Resin never seem to end! We switched from database-backed sessions to clustered sessions due to issue whereby sessions did not invalidate immediately, which lead to people logging out and finding themselves still logged in. Now we find that sessions do not expire after the configured period of inactivity. I'm using Resin-Pro 3.1.7a in a three-node cluster. Is this a known issue or am I able to configure my way out of it? Does the logout code call session.invalidate()? Or are you relying on the timeout? invalidate() is the correct, reliable way of closing the session, while the timeout is heuristic. -- Scott rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd Bridewell Gate 9 Bridewell Place London EC4V 6AW Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ 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
[Resin-interest] Cluster sessions don't expire
My woes with clustered sessions and Resin never seem to end! We switched from database-backed sessions to clustered sessions due to issue whereby sessions did not invalidate immediately, which lead to people logging out and finding themselves still logged in. Now we find that sessions do not expire after the configured period of inactivity. I'm using Resin-Pro 3.1.7a in a three-node cluster. Is this a known issue or am I able to configure my way out of it? rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd Bridewell Gate 9 Bridewell Place London EC4V 6AW Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Cluster sessions don't expire
Yes, the logout code calls session.invalidate() and it works fine. I have some application logic in SessionListener.sessionDestroyed(...) which does some housekeeping after someone presses logout or their session times out, so it's important it's called. I'm finding that the session does not time out in the configured time (60 seconds) when, for instance, you close the browser, so SessionListener.sessionDestroyed() is not called. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 04 December 2008 16:27 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Cluster sessions don't expire On Dec 4, 2008, at 2:43 AM, Richard Grantham wrote: My woes with clustered sessions and Resin never seem to end! We switched from database-backed sessions to clustered sessions due to issue whereby sessions did not invalidate immediately, which lead to people logging out and finding themselves still logged in. Now we find that sessions do not expire after the configured period of inactivity. I'm using Resin-Pro 3.1.7a in a three-node cluster. Is this a known issue or am I able to configure my way out of it? Does the logout code call session.invalidate()? Or are you relying on the timeout? invalidate() is the correct, reliable way of closing the session, while the timeout is heuristic. -- Scott rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd Bridewell Gate 9 Bridewell Place London EC4V 6AW Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ 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] Logs not rotating correctly
I think it could be related to http://bugs.caucho.com/view.php?id=2941
as I see this error in the logs:
[2008-10-30 09:35:39.569] java.lang.UnsatisfiedLinkError:
com.caucho.vfs.JniFilePathImpl.nativeTruncate([BI)I
[2008-10-30 09:35:39.569] at
com.caucho.vfs.JniFilePathImpl.nativeTruncate(Native Method)
[2008-10-30 09:35:39.569] at
com.caucho.vfs.JniFilePathImpl.truncate(JniFilePathImpl.java:363)
[2008-10-30 09:35:39.569] at
com.caucho.vfs.Path.truncate(Path.java:940)
[2008-10-30 09:35:39.569] at
com.caucho.log.AbstractRolloverLog.movePathToArchive(AbstractRolloverLog
java:584)
[2008-10-30 09:35:39.569] at
com.caucho.log.AbstractRolloverLog.access$100(AbstractRolloverLog.java:5
9)
[2008-10-30 09:35:39.569] at
com.caucho.log.AbstractRolloverLog$ArchiveTask.run(AbstractRolloverLog.j
ava:827)
[2008-10-30 09:35:39.569] at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
[2008-10-30 09:35:39.569] at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
[2008-10-30 09:35:39.569] at java.lang.Thread.run(Thread.java:619)
This is meant to have been fixed in 3.1.7a but that's what I'm running
and I still see it.
Richard Grantham
Development
---
[EMAIL PROTECTED]
Limehouse Software Ltd
DDI: (020) 7566 3336
Main: (020) 7566 3320
Fax: (020) 7566 3321
Limehouse Software Ltd
Bridewell Gate
9 Bridewell Place
London
EC4V 6AW
Manchester Office:
3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR
Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400
Check out Limehouse Software's innovative solutions
www.limehousesoftware.co.uk - Transforming the way you publish and consult on
information
The information contained in this e-mail or in any attachments is confidential
and is intended solely for the named addressee only. Access to this e-mail by
anyone else is unauthorised. If you are not the intended recipient, please
notify Limehouse Software Ltd immediately by returning this e-mail to sender or
calling 020 7566 3320 and do not read, use or disseminate the information.
Opinions expressed in this e-mail are those of the sender and not necessarily
the company. Although an active anti-virus policy is operated, the company
accepts no liability for any damage caused by any virus transmitted by this
e-mail, including any attachments.-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Lockstone
Sent: 23 October 2008 05:05
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Logs not rotating correctly
I don't have a definitive answer for you. We're not currently running
3.1.x, so I don't have any direct experience with it. Have you tried
using rollover-size instead of rollover-period? Just to see if it makes
any difference. With 3.0.x standalone (on Windows), rollover- size works
fine.
If you can't get it working, I'd recommend filing a bug at
http://bugs.caucho.com/
Rob
On Oct 21, 2008, at 08:10, Richard Grantham wrote:
Sorry, you're right. All that is missing.
I'm running Resin 3.1.7a. My log configuration is as follows:
log name= path=logs/resin.log timestamp=[%Y-%m-%d %H:%M:%S.%s]
rollover-period=1D / stdout-log path=logs/stdout.log
timestamp=[%Y-%m-%d %H:%M:%S.%s] rollover-period=1D /
stderr-log path=logs/stderr.log timestamp=[%Y-%m-%d %H:%M:%S.%s]
rollover-period=1D / access-log path=logs/access.log format='%h
%l %u %t %r %s %b % {Referer}i %{User-Agent}i'
rollover-period=1D /
We don't run Resin with Apache as we use a hardware load balancer.
What I see happening is the log being rotated but a file handle is
maintained on access.log (it's all the logs mentioned above this is
happening with, not just access.log) and not recycled after the log is
rotated. The result is that the log is copied to another file but then
not cleared. It continues to be written to. Hope that makes sense.
rgds,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Lockstone
Sent: 15 October 2008 15:52
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Logs not rotating correctly
My first question would be why would you want to maintain (on an
ongoing
basis) access logs for what appears to be a pretty busy server?
An important piece of information that's missing is the version of
resin that you're running. I know from personal experience that older
versions, in the 2.x world, did not properly rotate log files.
Also, what settings for the logs do you have configured in your resin
configuration? If you're running resin with apache, then (usually)
apache is in control of the access logs, not resin. It's hard to tell
from what you've said how you have resin configured, standalone or
with apache.
Rob
On Oct 15, 2008, at 04:33, Richard Grantham wrote:
Hi list,
I've got
[Resin-interest] Logs not rotating correctly
Hi list, I've got a major issue with our live servers. The logs don't appear to be rotating correctly. This is filling the disk and causing performance issues. Resin is running as the resin user - therefore will have reduced permissions but, even so, this shouldn't be happening as that user is the owner of the folder that is being written to. Any ideas on how to sort this or is it a bug? [EMAIL PROTECTED] logs]# ls -l total 3431672 -rw-r--r-- 1 resin apache 1073979392 Oct 15 11:30 access.log -rw-r--r-- 1 resin apache 1073745275 Oct 15 00:50 access.log.20081015 -rw-r--r-- 1 resin apache 1073892465 Oct 15 00:52 access.log.20081015.0052 -rw-r--r-- 1 resin apache 49848320 Oct 15 00:54 access.log.20081015.0054 -rw-r--r-- 1 resin apache 0 Oct 15 00:56 access.log.20081015.0056 -rw-r--r-- 1 resin apache 0 Oct 15 00:58 access.log.20081015.0058 -rw-r--r-- 1 resin apache 0 Oct 15 01:00 access.log.20081015.0100 -rw-r--r-- 1 resin apache 0 Oct 15 01:02 access.log.20081015.0102 -rw-r--r-- 1 resin apache 0 Oct 15 01:04 access.log.20081015.0104 -rw-r--r-- 1 resin apache 0 Oct 15 01:06 access.log.20081015.0106 -rw-r--r-- 1 resin apache 0 Oct 15 01:08 access.log.20081015.0108 -rw-r--r-- 1 resin apache 0 Oct 15 01:10 access.log.20081015.0110 -rw-r--r-- 1 resin apache 0 Oct 15 01:12 access.log.20081015.0112 -rw-r--r-- 1 resin apache 0 Oct 15 01:14 access.log.20081015.0114 -rw-r--r-- 1 resin apache 0 Oct 15 01:16 access.log.20081015.0116 -rw-r--r-- 1 resin apache 0 Oct 15 01:18 access.log.20081015.0118 -rw-r--r-- 1 resin apache 0 Oct 15 01:20 access.log.20081015.0120 -rw-r--r-- 1 resin apache 0 Oct 15 01:22 access.log.20081015.0122 -rw-r--r-- 1 resin apache 0 Oct 15 01:24 access.log.20081015.0124 -rw-r--r-- 1 resin apache 0 Oct 15 01:26 access.log.20081015.0126 -rw-r--r-- 1 resin apache 0 Oct 15 01:28 access.log.20081015.0128 -rw-r--r-- 1 resin apache 0 Oct 15 01:30 access.log.20081015.0130 -rw-r--r-- 1 resin apache 0 Oct 15 01:32 access.log.20081015.0132 -rw-r--r-- 1 resin apache 0 Oct 15 01:34 access.log.20081015.0134 -rw-r--r-- 1 resin apache 0 Oct 15 01:36 access.log.20081015.0136 -rw-r--r-- 1 resin apache 0 Oct 15 01:38 access.log.20081015.0138 -rw-r--r-- 1 resin apache 0 Oct 15 01:40 access.log.20081015.0140 -rw-r--r-- 1 resin apache 0 Oct 15 01:42 access.log.20081015.0142 -rw-r--r-- 1 resin apache 0 Oct 15 01:44 access.log.20081015.0144 -rw-r--r-- 1 resin apache 0 Oct 15 01:46 access.log.20081015.0146 -rw-r--r-- 1 resin apache 0 Oct 15 01:48 access.log.20081015.0148 -rw-r--r-- 1 resin apache 0 Oct 15 01:50 access.log.20081015.0150 -rw-r--r-- 1 resin apache 0 Oct 15 01:52 access.log.20081015.0152 -rw-r--r-- 1 resin apache 0 Oct 15 01:54 access.log.20081015.0154 -rw-r--r-- 1 resin apache 0 Oct 15 01:56 access.log.20081015.0156 -rw-r--r-- 1 resin apache 0 Oct 15 01:58 access.log.20081015.0158 -rw-r--r-- 1 resin apache 0 Oct 15 02:00 access.log.20081015.0200 -rw-r--r-- 1 resin apache 0 Oct 15 02:02 access.log.20081015.0202 -rw-r--r-- 1 resin apache 0 Oct 15 02:04 access.log.20081015.0204 -rw-r--r-- 1 resin apache 0 Oct 15 02:06 access.log.20081015.0206 -rw-r--r-- 1 resin apache 0 Oct 15 02:08 access.log.20081015.0208 Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd Bridewell Gate 9 Bridewell Place London EC4V 6AW Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HttpSession.invalidate() doesn't
Hi Eric When I hit a my logout servlet I forward the request to a page which will redirect to a protected page - forcing a login screen to be shown. Occasionally, when I logout I will go through this process and find myself still authenticated when I hit the protected resource, thus being logged in still. I upgraded from Resin 3.0.26. I find it happens even with a low number of sessions. I'm experimenting with using the cluster session config instead. Before, I was forced to use JDBC sessions due to issues with scaling. I also see a difference in the number of sessions reported by each Resin node and the number in the database. Incidentally, as recommended I was using MySQL for the session database before moving it over to SQL Server 2005 (as with our application database). Before the upgrade to Resin 3.1 I experienced issues with sessions not invalidating properly far more frequently with MySQL than SQL Server. rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Kreiser Sent: 07 October 2008 16:33 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't what are you seeing happen? what resin version did you upgrade from? I am looking at an issue currently where I have thousands of SessionImpl instances that seem like they should be GCed but are not. I am running resin pro 3.1.6 and just moved to resin pro 3.1.7a to see if I still have the same problem. I am using db persisted sessions, so I am see the number of sessions in the db verses the number of sessions reported by resin using jmx. Richard Grantham wrote: Hi list, I recently upgraded to Resin Professional 3.1.7a in the hope that the issues I had would be solved. For the most part they are, however, there are occasions when session.invalidate() still doesn't quite work and you have to logout twice. My resin-web.xml session configuration looks like this: session-config use-persistent-store=true reuse-session-id=false invalidate-after-listener=true cookie-secure=true enable-url-rewriting=false / Is there anything else, configuration wise, that I may have missed that could be causing this issue? rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Grantham Sent: 23 June 2008 14:48 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I've found that this could well be the cause of another related issue which has been causing me misery for the last few months. My 403.jsp has an element on it which is the result of a Web service call called via a tag. The call is made only if a person of the correct type is logged in as the call is protected by J2EE security. If nobody is logged in then a login box is displayed. When the Web service is called it is always done to the same server as displaying the 403 page. There have been several occasions when the JSP will display the 403 page and make the Web service call which will return a 403 which will make the call which will return a 403, etc. etc. etc. until Resin maxes out its thread, hangs and needs to be restarted. To my mind this would only happen if the wrong session was being pulled up with the call to request.getSession() in my tag. Any pointers as how to debug and solve this would be very much appreciated. For now I have removed the page element. rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Grantham Sent: 18 June 2008 12:47 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I upgraded to Resin 3.0.26 and while the problem has certainly eased in frequency it has not disappeared. I have taken out the always-save / element. This wouldn't effect things would it? rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN
[Resin-interest] XML Streaming issue with XFire and Resin 3.1.6
Hi list, I'm still in the process of trying to move our application over to Resin 3.1.6. I had an out-standing issue with incorrect SOAP responses coming from Xfire 1.2.6. My SOAP responses follow this pattern: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soap:Body ns1:methodResponse xmlns:ns1=http://mynamespace; ns1:result firstElement xmlns=http://mynamespace; / secondElement / thirdElement / /ns1:result /ns1:methodResponse /soap:Body /soap:Envelope Only firstElement has namespace declaration. This is incorrect. All elements should have this namespace declaration. I guess this is an bug with Resin's streaming XML implementation. By configuring Resin to use STaX instead I solved the issue I was having. Is this a known issue or should I log it? rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] XSLT and Resin 3.1.6
Hi list, I've been trying to move our application from Resin 3.0.26 to Resin 3.1.6. I'm stuck with a major issue I cannot for the life of me solve. Some help or assistance would be good. Basically, our XSLTs have stopped working properly. Templates do not seem to match. We use Saxon for XSLT transformations and I have confirmed that it is definitely being used over Resin's own XSLT transformer. The particular code that's failing looks like this: Writer writer = new StringWriter(); Reader reader = null; Transformer transformer = getTransformer(xsl); Reader reader = new InputStreamReader(new ByteArrayInputStream(xml.getBytes(UTF-8)), UTF-8); transformer.transform(new StreamSource(reader), new StreamResult(writer)); return writer.toString(); Any ideas why upgrading Resin would break transformations? rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HttpSession.invalidate() doesn't
I've found that this could well be the cause of another related issue which has been causing me misery for the last few months. My 403.jsp has an element on it which is the result of a Web service call called via a tag. The call is made only if a person of the correct type is logged in as the call is protected by J2EE security. If nobody is logged in then a login box is displayed. When the Web service is called it is always done to the same server as displaying the 403 page. There have been several occasions when the JSP will display the 403 page and make the Web service call which will return a 403 which will make the call which will return a 403, etc. etc. etc. until Resin maxes out its thread, hangs and needs to be restarted. To my mind this would only happen if the wrong session was being pulled up with the call to request.getSession() in my tag. Any pointers as how to debug and solve this would be very much appreciated. For now I have removed the page element. rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Grantham Sent: 18 June 2008 12:47 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I upgraded to Resin 3.0.26 and while the problem has certainly eased in frequency it has not disappeared. I have taken out the always-save / element. This wouldn't effect things would it? rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments.-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: 17 June 2008 14:17 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: persistent-store type=jdbc init data-sourcejdbc/session/data-source always-load / always-save / /init /persistent-store What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. I believe that problem is addressed in 3.0.26, issue #2485 reported in the change log here: http://www.caucho.com/resin-3.0/features/changes.xtp PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. There were a number if cluster store issues reported in the 3.1 branch, but the remaining issues in 3.0 have generally not been reported to us, we found them by doing increased stress testing for the 3.1 release. Take care, -- Sam ___ 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] HttpSession.invalidate() doesn't
Hi list, I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: persistent-store type=jdbc init data-sourcejdbc/session/data-source always-load / always-save / /init /persistent-store What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. Little help? rgds, Richard PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] HttpSession.invalidate() doesn't
Thanks Sam. I'll give it a go. Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments.-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: 17 June 2008 14:17 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] HttpSession.invalidate() doesn't I'm using resin-pro-3.0.25 in a three-server cluster with session persistence configured using a MySQL database: persistent-store type=jdbc init data-sourcejdbc/session/data-source always-load / always-save / /init /persistent-store What I'm finding is that you can click logout up to 7 or 8 times before your session actually gets invalidated. The implementation of HttpSessionListener is doing its thing. The logout servlet is doing its thing but from what I can see the req.getSession().invalidate() call is NOT being respected. I believe that problem is addressed in 3.0.26, issue #2485 reported in the change log here: http://www.caucho.com/resin-3.0/features/changes.xtp PS. I am loath to switch (back) to using clustered sessions as I've had issues with random logouts and loads of timeout errors in the logs related to the internal Resin session store. There were a number if cluster store issues reported in the 3.1 branch, but the remaining issues in 3.0 have generally not been reported to us, we found them by doing increased stress testing for the 3.1 release. Take care, -- Sam ___ 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 clustered session store
I've upgraded to 3.0.25 but I'm still seeing lots of session issues. One little bit or weirdness that I hope someone can answer is how the session database managed to shrink from around the 500MB mark to the 20MB mark. This seems to be a major drop in the space used. Also, I got an error whereby it tried to write an object of over 64mb to the file store, which gave an error. Now, I've checked through my application and I'm pretty sure that nothing is storing an object of that size in the session. I saw this bug: http://bugs.caucho.com/view.php?id=848 Could they be related? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Grantham Sent: 14 January 2008 16:54 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store Thanks for the response Scott. We did some firewall reconfiguration with regards to connections and sessions and the issue appears to have gone away. I've not tried the 3.1 branch in a while as we found it didn't play well with XFire, but I will upgrade to 3.0.25 ASAP. rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 14 January 2008 16:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Jan 10, 2008, at 4:19 AM, Richard Grantham wrote: Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: We've made a few fixes to the synchronization/timing of the clustered session. Some in 3.0.25, but many more in 3.1. However, I was never able to reproduce that exact error here, so if anyone runs into this on 3.1.4 or later, it would be very helpful to send a bug report on the issue with as much detail as possible. -- Scott [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject $DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionManager.getSession (SessionManager.java: 1278) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.createSession (AbstractH ttpRequest.java:1444) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttp Request.java:1256) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.writeHeaders (AbstractH ttpResponse.java:1556) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeHeaders (ResponseStream. java:216) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeNext (ResponseStream.jav a:401) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushByteBuffer (ToByte ResponseStream.java:518) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushBuffer (ToByteResp onseStream.java:424) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.finish (ResponseStream.java:6 64) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.close (ResponseStream.java:79 6) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.finish (AbstractHttpRes ponse.java:1956) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.close (AbstractHttpResp onse.java:260) [2008-01-10 11:31:01.379] at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.ja va:190) [2008-01-10 11:31:01.379] at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.j ava:229) [2008-01-10 11:31:01.379] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) [2008-01-10 11:31:01.379
Re: [Resin-interest] Resin clustered session store
Thanks for the response Scott. We did some firewall reconfiguration with regards to connections and sessions and the issue appears to have gone away. I've not tried the 3.1 branch in a while as we found it didn't play well with XFire, but I will upgrade to 3.0.25 ASAP. rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 14 January 2008 16:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Jan 10, 2008, at 4:19 AM, Richard Grantham wrote: Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: We've made a few fixes to the synchronization/timing of the clustered session. Some in 3.0.25, but many more in 3.1. However, I was never able to reproduce that exact error here, so if anyone runs into this on 3.1.4 or later, it would be very helpful to send a bug report on the issue with as much detail as possible. -- Scott [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject $DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionManager.getSession (SessionManager.java: 1278) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.createSession (AbstractH ttpRequest.java:1444) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttp Request.java:1256) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.writeHeaders (AbstractH ttpResponse.java:1556) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeHeaders (ResponseStream. java:216) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeNext (ResponseStream.jav a:401) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushByteBuffer (ToByte ResponseStream.java:518) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushBuffer (ToByteResp onseStream.java:424) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.finish (ResponseStream.java:6 64) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.close (ResponseStream.java:79 6) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.finish (AbstractHttpRes ponse.java:1956) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.close (AbstractHttpResp onse.java:260) [2008-01-10 11:31:01.379] at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.ja va:190) [2008-01-10 11:31:01.379] at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.j ava:229) [2008-01-10 11:31:01.379] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) [2008-01-10 11:31:01.379] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.run(ThreadPool.java:442) [2008-01-10 11:31:01.379] at java.lang.Thread.run(Thread.java: 619) The servers are configured to persist sessions across the cluster. On both servers the size of the DB file is 500M. It doesn't grow or shrink. Is this normal? I'm concerned as to what's causing the above error. The (hardware) load balancer has been reporting that it has reached it's maximum number of sessions. Could this be playing a part? Any assistance would be appreciated. rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd
Re: [Resin-interest] Resin clustered session store
We would send valid SOAP requests but XFire was not interpretting parameters correctly. Eg. This SOAP request: soap:Envelope xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; soap:Body list deepfalse/deep /list /soap:Body /soap:Envelope would give this response: 2007-08-08 09:59:03,894 ERROR [resin-tcp-connection-*:80-14] (DefaultFaultHandler.java:35) - Fault occurred! org.codehaus.xfire.XFireRuntimeException: Invalid boolean value: at org.codehaus.xfire.aegis.AbstractMessageReader.getValueAsBoolean(Abstrac tMessageReader.java:115) at org.codehaus.xfire.aegis.type.basic.BooleanType.readObject(BooleanType.j ava:16) at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBinding Provider.java:169) at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding. java:206) at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBin ding.java:51) at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.j ava:42) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:1 31) at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.j ava:64) at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.jav a:38) at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireSer vletController.java:304) at org.codehaus.xfire.transport.http.XFireServletController.doService(XFire ServletController.java:129) at org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java: 116) at javax.servlet.http.HttpServlet.service(HttpServlet.java:153) at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChai n.java:103) The only difference would be the version of Resin used. I think someone else posted a question about it to the XFire mailing list and didn't receive a response. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emil Ong Sent: 14 January 2008 17:38 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Mon, Jan 14, 2008 at 04:54:19PM -, Richard Grantham wrote: Thanks for the response Scott. We did some firewall reconfiguration with regards to connections and sessions and the issue appears to have gone away. I've not tried the 3.1 branch in a while as we found it didn't play well with XFire, but I will upgrade to 3.0.25 ASAP. Hi Richard, What problems did you run into with XFire and 3.1? We want to make sure they work well together. Thanks, Emil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 14 January 2008 16:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Jan 10, 2008, at 4:19 AM, Richard Grantham wrote: Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: We've made a few fixes to the synchronization/timing of the clustered session. Some in 3.0.25, but many more in 3.1. However, I was never able to reproduce that exact error here, so if anyone runs into this on 3.1.4 or later, it would be very helpful to send a bug report on the issue with as much detail as possible. -- Scott [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject $DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379
[Resin-interest] Resin clustered session store
Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject$DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionManager.getSession(SessionManager.java: 1278) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.createSession(AbstractH ttpRequest.java:1444) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.getSession(AbstractHttp Request.java:1256) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.writeHeaders(AbstractH ttpResponse.java:1556) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeHeaders(ResponseStream. java:216) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeNext(ResponseStream.jav a:401) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushByteBuffer(ToByte ResponseStream.java:518) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushBuffer(ToByteResp onseStream.java:424) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.finish(ResponseStream.java:6 64) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.close(ResponseStream.java:79 6) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.finish(AbstractHttpRes ponse.java:1956) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.close(AbstractHttpResp onse.java:260) [2008-01-10 11:31:01.379] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.ja va:190) [2008-01-10 11:31:01.379] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.j ava:229) [2008-01-10 11:31:01.379] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) [2008-01-10 11:31:01.379] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.run(ThreadPool.java:442) [2008-01-10 11:31:01.379] at java.lang.Thread.run(Thread.java:619) The servers are configured to persist sessions across the cluster. On both servers the size of the DB file is 500M. It doesn't grow or shrink. Is this normal? I'm concerned as to what's causing the above error. The (hardware) load balancer has been reporting that it has reached it's maximum number of sessions. Could this be playing a part? Any assistance would be appreciated. rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any
[Resin-interest] IllegalStateException on com.caucho.server.cluster.ClusterObject.load
I'm running resin-pro-3.0.23 and have seen a lot of these errors in my logs today: java.lang.IllegalStateException at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:253) at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) at com.caucho.server.session.SessionManager.getSession(SessionManager.java: 1278) at com.caucho.server.connection.AbstractHttpRequest.createSession(AbstractH ttpRequest.java:1444) at com.caucho.server.connection.AbstractHttpRequest.getSession(AbstractHttp Request.java:1256) at com.caucho.server.connection.RequestWrapper.getSession(RequestWrapper.ja va:534) at com.caucho.server.connection.RequestAdapter.getSession(RequestAdapter.ja va:383) at com.caucho.server.webapp.DispatchRequest.getSession(DispatchRequest.java :435) at _jsp._errors._500__jsp._jspService(_500__jsp.java:24) at com.caucho.jsp.JavaPage.service(JavaPage.java:60) at com.caucho.jsp.Page.pageservice(Page.java:570) at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java :179) at com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChai n.java:115) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.j ava:229) at com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcher Impl.java:277) at com.caucho.server.webapp.RequestDispatcherImpl.error(RequestDispatcherIm pl.java:113) at com.caucho.server.webapp.ErrorPageManager.sendServletError(ErrorPageMana ger.java:362) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.ja va:175) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.j ava:229) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) at com.caucho.util.ThreadPool.run(ThreadPool.java:442) at java.lang.Thread.run(Thread.java:619) Is this a known bug for the 3.0 branch or am I doing something wrong? I've seen the bug logged at http://bugs.caucho.com/view.php?id=1897 but I can't run the 3.1 branch as it has issue with XFire. rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd 4th Floor 1 London Bridge London SE1 9BG Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
