You
don't mention which version of framework or tec you have installed, but if it is
a recent one (tec 3.7.1, fw 3.7.1) then you can use the tuning in the
tecad_nv6k.conf to control how fast you want the adapter to send events - this
is also true to a lesser extent in previous versions. This would allow you
to manage the hit on your NV server when TEC comes back up. Indeed it will
allow you to control how much pain NV causes TEC when it restarts!
Check
out the TEC Adapters guide PDF - it goes through a whole load of
parameters. Some of these may be useful (explained in the PDF)
BufEvtMaxSize, BufferEvents, BufferFlushRate, ConnectionMode, FilterCache (be
careful about impact on TEC rules!), RetryInterval.
hth
Karl
Karl Prinelle
Tivoli Certified
Consultant
Elyzium Ltd
Enterprise Systems Management
Consultants
Mobile: +44 (0)7813 189198
---------------------------------------------------------------------------
Elyzium Disclaimer:
This email transmission is confidential and intended solely for the person or
organisation to whom it is addressed. If you are not the intended recipient, you
must not copy, distribute or disseminate the information, or take any action in
reliance of it. Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views of any
organisation or employer. If you have received this message in error, do not
open any attachment but please notify the sender (above) deleting this message
from your system. Please rely on your own virus check no responsibility is taken
by the sender for any damage rising out of any bug or virus infection.
---------------------------------------------------------------------------
Re-sending to list.......
I believe wpostemsg and postemsg will both cache events if the TEC
server is not available. NetView's nvserverd certainly caches events if the
TEC Server is unavailable or if you have a communications problem. NetView's
nvserverd basically uses the same code as postemsg to forward events to a TEC
server. So you may simply need to re-check your configuration to see why you
are not caching.
I think you would
be hard pressed to measure a difference between wpostemsg and postemsg.
wpostemsg uses the Framework's oserv to oserv communication's path, where as
postemsg simply pipes it across an IP socket as a standard tcpip packet. If I
was to guess, I would think there would be more overhead using wpostemsg since
the oserv to oserv communuications still uses tcpip but obviously with a lot
more encapsulation. The overhead would be on your tcpip stack if
anywhere.
I hope this
helps,
Gareth Holl Software
Engineer gholl AT us.ibm DOT com
IBM Software Group - Tivoli
Brand Research Triangle Park, North Carolina.
| anand anupam
<ananda AT bharatpetroleum DOT com>
08/27/2002 02:50 AM
| To:
nv-l AT lists.tivoli DOT com cc:
Subject: [nv-l] Does wpostemsg causes
stress to NetView server
|
Hi,
We are having NetView 6.0.2
on AIX4.3.3 which is being integrated to TEC.
We started with postemsg
command to send alerts to TEC but now we wanted to do wpostemsg instead of
postemsg just to take care of missed events when TEC is not available. As
wpostemsg will queue the events when TEC is not available and will deliver
when TEC becomes available.
My concern is that wpostemsg
will further stress the NetView server which is already having performance
issues. Can anybody suggest is wpostemsg will really stress the NetView or
not? And if yes, what is the work around?
Thanks,
Anupam
******************************************Disclaimer************************************* The
information contained in this message is BPCL's Confidential and Proprietary
information and is intended only for the use of the recipient(s) named above.
If the reader of this message is not the intended recipient, he/she is
hereby notified that any use, dissemination, distribution, or copying of this
communication or any of its content is strictly prohibited. In such
case, please advise the sender immediately and delete it from your system.
Further acknowledges that any views expressed in this message are those
of the individual sender and no binding nature of the message shall be implied
or assumed unless the sender does so expressly with due authority of
BPCL.
********************************************************************************************
|