Very open ended question. First to address one issue , ANY application
server is exposed to thread safety issues.
Use WebSphere/Portal, JBOSS etc, if you have poor or no resource
management, failures will result.
As to enabling run web agents currently, This is critical for high use
agents,
Without this enabled, only 1 instance of an agent can run at a time, this
can cause significant performance issues if the agent is a high use call.
Lets assume you have a agent that is called , requiring 2 seconds to
process, if 2 users make the request at the same time, 1 user isn't
getting a result till 4 seconds has passed.
More users, longer wait, the experience will be "hit or Miss" depending
on if you are first or last in the queue to wait for the agent.
There are a number of thread safety issues to consider.
Resource safety - in memory objects , ensure they are not "touched" by
other than the owning process.
Data safety - manage data to avoid or manage concurrent writes to data ,
or alteration of data during read.
In Domino we have 3 "languages" which an agent could be written in.
Formula language (simple scripting originally not designed to be exposed
to a multithread environment)
LotusScript (Most of which has been made thread safe).
Java (thread safe).
In the above cases I refer to resource safety. Anything written in LS or
Java is resource thread safe. For Formula the designer help for each call
defines it's thread safety.
No language is by design data thread safe.
The VAST majority of customer issues are Data NOT resource safety issues.
Domino provides some features to manage data safety issues.
Document locking.
This prevents multiple writes to the same document from
unique instances of the agent.
Read locks can also be used if the applications work from
"unread" state, this is valuable.
Failing to manage data write/read conflicts can result in "data
loss", unexpected errors or results from the agent.
The single most common application issue on Domino is view contention.
As all data is accessed via a view, managing the view is critical
to performance.
The majority of customer applications take no consideration for
the performance impacts of view design.
View indexes are single threaded for update (There is only 1 view
index per view)
During update, it is locked, If the time to update the view is
longer than the interval between changes in the view, the view will ALWAYs
require an update
Users will queue up waiting for the view to update,
leading to semaphore timeouts and "hangs of the server"
This isn't really a hang at all. but a performance issue.
Most commonly this problem happens after the application
has been in service a long time
As users add documents to the database the view
complexity grows increasing the time to update the index.
Walter Scanlan
Senior Software Engineer
Office: 1 720 342 5837
Cell: 507-990-4539
From: "Crump, Mike" <Mike.Crump@xxxxxxxxxxxxxxxx>
To: "Lotus Domino on the iSeries / AS400" <domino400@xxxxxxxxxxxx>,
Date: 05/11/2011 09:12 AM
Subject: Thread safe agents - run web agents concurrently
Sent by: domino400-bounces+wscanlan=us.ibm.com@xxxxxxxxxxxx
I just started looking at this. Has anyone gone through a process to
enforce/engage/initiate the use of thread safe coding techniques?
This is based on the assumption that we desire/need to allow the
concurrent running of web agents. I say assumption because I had gone
through a period of time where we had numerous issues with semaphore
locks (almost all caused by HTTP agents) that I would typify as
coding/logic problems. Most of those have been cleaned up. However, we
just had another 'blip' and conceptually this bothers me. If we have a
web agent that misbehaves (for whatever reason) it has the ability to
impact all other web agents/applications.
Our applications are 99% Domino. We only have a few functions that are
Notes based. When the HTTP side goes black or brown I get all kinds of
noise about the server locking up. It has taking some convincing to get
some developers to step up and clean up some questionable practices.
However, it has me thinking architecturally about the risk of being
synchronous and then I also have the nay-sayers who can't believe that
Domino has this single thread risk.
It would seem that if you don't have these coding problems or an over
busy server the gain may not be great. It also seems that this is not
an easy to solve and manage solution based on what I'm reading.
Tools?
Practices?
Experience?
Is the pain worth the gain?
Michael Crump
Manager, Computing Services
Verallia
SGCI
1509 S. Macedonia Ave.
Muncie, IN 47302
765.741.7696
765.741.7012 f
www.verallia.com <
http://www.verallia.com/>
Stupidity
Quitters never win, winners never quit, but those who never win AND
never quit are idiots.
This email and its attachments may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any view
or opinions expressed are solely those of the author and do not
necessarily represent those of Saint-Gobain. If you are not the
intended recipient of this email and its attachments, you must take no
action based upon them, nor must you copy or show them to anyone.
Please contact the sender if you believe you have received this email in
error.
_______________________________________________
This is the Lotus Domino on the iSeries / AS400 (Domino400) mailing list
To post a message email: Domino400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/domino400
or email: Domino400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/domino400.
midrange.com
