Re: [uportal-dev] synchronized code in CPortletAdapter

[Eric Dalquist]

If memory serves I think Andrew Petro did some work between 2.5 and 2.6 to convert CPortletAdaptor from an IMultithreadedChannel to a plain IChannel. The result would have been that the synchronized method would be scoped to the CPortletAdaptor instance and there would be one instance per user per subscribed portlet, effectively negating the synchronization.

-Eric

Paul Gazda wrote:

Hi Eric.








Paul Gazda

We are on the path to 3.x, but are going to 2.6.1 first (almost there). Comparing the 2.6.1 code to 2.5.2, I see that the synchronized channelStateMap has been removed, but the synchronized methods and code blocks are still there. I'm guessing it will be 6 to 12 months before we are on 3.x. What we are finding is that when we have temporary slowdowns in the response of our database queries (the causes of which are still unclear), the single threading of the CPortletAdapter seems to quickly magnify the effect, and pretty soon every portlet is timing out, users get no response for minutes at a time, and it takes a long time for the system to stabilize again. It would be nice if we could fix the single threading issue before going to 3.x. Without going into detail, do you know off the top of your head whether the thread safe changes in CPortletAdapter would be easy or difficult? Is it something best left alone? *From:* bounce-8321330-5712...@lists.wisc.edu [mailto:bounce-8321330-5712...@lists.wisc.edu] *On Behalf Of *Eric Dalquist

*Sent:* Wednesday, November 04, 2009 5:40 PM
*To:* uportal-dev@lists.ja-sig.org
*Subject:* Re: [uportal-dev] synchronized code in CPortletAdapter




-Eric
(another good reason to upgrade to 3.x ;) )

Paul Gazda wrote:




Paul Gazda


--

I think it may have been removed in 2.6 but I believe it can't simply be removed. I believe there are changes required to those methods to make them thread safe. We are running uP 2.5.2. I see that there are 2 methods and 2 code blocks that are synchronized in CPortletAdapter and am just wondering what the reason is for the single threading in such a heavily used class. Thanks. You are currently subscribed to uportal-dev@lists.ja-sig.org <mailto:uportal-dev@lists.ja-sig.org> as: eric.dalqu...@doit.wisc.edu <mailto:eric.dalqu...@doit.wisc.edu>

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

smime.p7s
Description: S/MIME Cryptographic Signature