[Building Sakai] [Announcements] CLE Project Coordination Summary
Adrian Fish
a.fish at lancaster.ac.uk
Wed Jun 15 03:16:51 PDT 2011
I read the more detailed notes on the neoportal chat concerns. Here goes:
"Chuck H expressed concerns about jgroups given experience with jforum"
What were the problems with JForum and JGroups? Portal chat messages are
miniscule (<1K typically). If JForum was using JGroups to move chunks of
markup around ...
"AZ amq and jgroups is pretty costly"
Who says? Costly in what way? It may be true but this statement seems to
be based on fact.
"There is also the heartbeat call which checks if you are online. The
ActivityService API provides this already, and is sakai event
based/cached (and has an entity provider)"
The heartbeat is implied by the getLatestData call. It's not a separate
call and it would be bad performance practice to make it so. Portal chat
makes one getLatestData call on a schedule. All the data it needs gets
returned by that call and the heartbeat gets stamped. Also, if people
were just using portal chat, would portal chat have to fire an event
every time a message got sent just to keep ActivityService in the loop?
What if people do nothing else apart from chat for half an hour? The
advantage of the heartbeat is that it indicates that the chat client is
up and running for that user; even if they are doing nothing else, they
are still marked as available for chatting.
"The dependency has been resolved by using reflection to check if P2 is
available. This particular case could be resolved by EB instead.
Possibly preferred over using reflection, EB lookup is low cost (SM, AZ,
SS)"
Why would an EB call be preferred? What's wrong with reflection? I'm
open to persuasion.
Cheers again,
Adrian.
On 15/06/2011 10:30, Adrian Fish wrote:
> A fair concern. How can we go about testing this in a realistic fashion?
>
> There are some results from load tests run by the JBoss community here:
> http://www.jgroups.org/perf/perf2008/Report.html
>
> Don't know how meaningful they are in the real world of a big Sakai
> deployment but they at least seem to indicate an ability to scale. For
> a 10 node cluster these tests yielded a throughput of around 35K 1KB
> messages per second. Portal chat messages are very small :)
>
> Cheers,
> Adrian.
>
> On 14/06/2011 22:04, David Horwitz wrote:
>> Also we have no idea as to performance on large scale production systems.
>>
>> D
>>
>> On 06/14/2011 10:56 PM, May, Megan Marie wrote:
>>>
>>> Hi Adrian,
>>>
>>> It was discussed extensively at the meetings and it was suggested
>>> that a different technology might work better. The notes [3] are
>>> posted and reflect some of those concerns. I think we can all
>>> agree that it's important to be prudent for any change that has
>>> performance implications.
>>>
>>> Looking forward to exploring this topic more,
>>>
>>> Megan
>>>
>>> [3] Notes: http://etherpad.ctools.org/CLEPROJCOR-2011-06-12
>>>
>>> *From:*Adrian Fish [mailto:a.fish at lancaster.ac.uk]
>>> *Sent:* Tuesday, June 14, 2011 1:57 AM
>>> *To:* May, Megan Marie
>>> *Cc:* announcements at collab.sakaiproject.org; Sakai Development
>>> (sakai-dev at collab.sakaiproject.org);
>>> management at collab.sakaiproject.org; sakai2-tcc Committee
>>> *Subject:* Re: [Announcements] CLE Project Coordination Summary
>>>
>>> Got to ask why JGroups is seen as so risky in neochat? If neochat is
>>> disabled nobody will try it and it will just die; you may as well
>>> just put it out of its misery now.
>>>
>>> Cheers,
>>> Adrian.
>>>
>>> On 14/06/2011 09:31, May, Megan Marie wrote:
>>>
>>> Colleagues,
>>>
>>> On Saturday, June 12^th a group met in person to discuss
>>> opportunities and challenges within the CLE community. One
>>> discussion strove to build consensus about changes to the next CLE
>>> minor release, 2.9.0, and the following proposals are being
>>> circulated to the community for additional comment:
>>>
>>> Inclusion of NeoPortal.
>>>
>>> The chat showcased with this new portal should be disabled until the
>>> technology is reviewed and performance tested
>>>
>>> Inclusion of Lesson Builder, a way to structure content, will be
>>> included in provisional (ie stealthed) status
>>>
>>> Inclusion of Mailsender, a drop-in replacement for the deprecated
>>> Mailtool, as a core tool
>>>
>>> CKeditor will be the default editor for 2.9
>>>
>>> Inclusion of News Feeds as a core tool and the deprecation of the
>>> current New tool
>>>
>>> Inclusion of soft delete for sites & resources
>>>
>>> End support for Oracle 9i going forward (in the 2.8.x code line,
>>> this would begin with 2.8.1)
>>>
>>> Recommended version of MySQL is minimally 5.1
>>>
>>> Recommended JDK is minimally 1.6
>>>
>>> Upgrade to Tomcat 7
>>>
>>> Upgrade to JSF 1.2 version (dependency on upgrade of Tomcat 7)
>>>
>>> Adoption of a release schedule [1] that closely mirrors that of 2.8.0
>>>
>>> Additionally, these are areas where the group was aware of
>>> significant work but needs to review further prior to consideration
>>> for inclusion in 2.9:
>>>
>>> Blogs
>>>
>>> Roster
>>>
>>> Many topics not tied to a specific release and/or relating to
>>> fostering the CLE ecosystem were discussed throughout the rest of
>>> the day. Below is a quick summary of each of discussion that
>>> identified steps forward.
>>>
>>> *//*
>>>
>>> */Sakai.Properties/*
>>>
>>> Currently there is no definitive list of all properties (ie
>>> sakai.properites) and results in implementers not knowing the
>>> possibilities with the Sakai CLE product. Going forward, more
>>> discussion needs to occur to look at how this can be best accomplished
>>>
>>> *//*
>>>
>>> */Revised Build /*
>>>
>>> We discussed a proposal for improving the current build and release
>>> process in order to provide a more efficient workflow. Some minor
>>> changes will be further described and tested.
>>>
>>> *//*
>>>
>>> */Confluence /*
>>>
>>> There is a large amount of out of date/ inaccurate information
>>> currently in Confluence. The community needs to have authoritative
>>> documentation; particularly in the areas like "Getting Started" (ie
>>> for faculty, admins), marketing materials, and with release
>>> information like release notes, system admin guides, ect .
>>>
>>> Confluence has been central to the community and a section of
>>> confluence with restricted write access needs to be established.
>>> Other spaces will be tagged to indicate that they are community
>>> contributions. Longer term out of date information should be moved
>>> into accessible archive location to preserve the history of the project.
>>>
>>> *//*
>>>
>>> */JIRA/*
>>>
>>> The group discussed proposals for addressing the large backlog of
>>> JIRA issues, such as providing a workflow for JIRA, better
>>> communicating the existing process to the community, and some other
>>> minor improvements.
>>>
>>> *//*
>>>
>>> */Work toward building the CLE Development team/*
>>>
>>> There have been many teams (RM, MT, Project Leads) working within
>>> the CLE. It's time to start bringing these groups together to
>>> build a cohesive team.
>>>
>>> A proposal for combining the Release Management & Maintenance Team
>>> calls into one "CLE Development Team" call every couple of weeks.
>>> These meetings would include both structured agenda and
>>> opportunities for questions and mentoring. Additional ideas for
>>> improving participation on the maintenance team were discussed,
>>> including what has and has not worked in the past.
>>>
>>> **
>>>
>>> *Sakai 2.10.0 Brainstorming*
>>>
>>> The group spent about an hour brainstorming areas to focus on for a
>>> 2.10.0 CLE release. Ideas shared during this time included: Session
>>> failover, import/export of content, improve the UI across the
>>> toolset, better stack trace error handling, move from using state to
>>> urls , QoS request, worker queue, gradebook and better UI support
>>> for large classes. A theme that emerged during this discussion was
>>> that addressing the top 10 places for each of the afore mentioned
>>> topics would move us to a significantly better place in terms of
>>> enhancing the CLE's place in the market place.
>>>
>>> **
>>>
>>> *Other Topics*
>>>
>>> The project coordination meeting ended with updates and status on
>>> several focus areas, including internationalization, accessibility
>>> and documentation.
>>>
>>> Additional information about each of these topics as well as the
>>> notes from the day are available off the agenda in Confluence [2].
>>>
>>> We want to encourage and welcome questions, comments and additional
>>> considerations.
>>>
>>> Thanks!
>>>
>>> Megan May
>>>
>>> Sakai CLE Technical Coordination Committee (TCC) Chair
>>>
>>> Beth Kirschner
>>>
>>> Sakai CLE Technical Coordination Committee (TCC) Vice Chair
>>>
>>> [1] Proposed 2.9.0 Schedule:
>>> https://confluence.sakaiproject.org/x/VIiCB
>>>
>>> [2] LA CLE Project Coordination:
>>> https://confluence.sakaiproject.org/x/vAV6B
>>>
>>>
>>>
>>> _______________________________________________
>>> announcements mailing list
>>> announcements at collab.sakaiproject.org <mailto:announcements at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/announcements
>>>
>>> TO UNSUBSCRIBE: send email toannouncements-unsubscribe at collab.sakaiproject.org <mailto:announcements-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
>>>
>>>
>>>
>>> --
>>> ==================================
>>> Adrian Fish
>>> Software Engineer
>>> Centre for e-Science
>>> Bowland Tower South C Floor
>>> Lancaster University
>>> Lancaster
>>> LA1 4YW
>>> email:a.fish at lancaster.ac.uk <mailto:a.fish at lancaster.ac.uk>
>>>
>>> http://confluence.sakaiproject.org/display/YAFT/Yaft
>>> http://confluence.sakaiproject.org/display/CLOG/Home
>>> http://confluence.sakaiproject.org/display/BBB/Home
>>>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email tosakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email tosakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
> --
> ==================================
> Adrian Fish
> Software Engineer
> Centre for e-Science
> Bowland Tower South C Floor
> Lancaster University
> Lancaster
> LA1 4YW
> email:a.fish at lancaster.ac.uk
>
> http://confluence.sakaiproject.org/display/YAFT/Yaft
> http://confluence.sakaiproject.org/display/CLOG/Home
> http://confluence.sakaiproject.org/display/BBB/Home
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
--
==================================
Adrian Fish
Software Engineer
Centre for e-Science
Bowland Tower South C Floor
Lancaster University
Lancaster
LA1 4YW
email: a.fish at lancaster.ac.uk
http://confluence.sakaiproject.org/display/YAFT/Yaft
http://confluence.sakaiproject.org/display/CLOG/Home
http://confluence.sakaiproject.org/display/BBB/Home
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110615/8e6f5e93/attachment.html
More information about the sakai-dev
mailing list