The end user of "recent releases" i.e. previous releases has not seen this
problem.
At least no report of the problem has been created until a few weeks ago.
It only occurs in overload situations and has only been seen in recent testing
with an overloaded system.
New ways of testing are always go
Please reproduce withe IMMD trace on.
/AndersBj
From: Sirisha Alla [mailto:sirisha.a...@oracle.com]
Sent: den 19 augusti 2015 11:07
To: [opensaf:tickets]; opensaf-tickets@lists.sourceforge.net
Subject: Re: [tickets] [opensaf:tickets] Re: #1291 IMM: IMMD healthcheck
callback timeout when standby
The reason this fix is done is to prevent that the log service makes it
impossible to enable long DNs.
Enabling the log service for long DNs is definitely an enhancement.
The problem is that currently the log, by doing a global iteration, will
encounter any long DN object if it exists and
then cr
For critical CCBs the wait can be indefinite since the delay can be due to
problems on the file system.
The AMF should not block a failover just because it can not attach as OI.
There is no inherent functional dependence of the AMF failover mechanism on
the AMF OI being available.
Any such depe
The imma_proc.c warning/error is a serious bug.
At some point cl_node->replyPending was changed from an uint8 to a bool.
What was not considered at that time was that this member is not just used for
synchronous downcalls
And reply, but also for the asynchronous om-admin-op downcall and its
c
The counter itself needs to be coherent, i.e. reside on a shared and always
accessible file system.
It also needs to be reset to zero after som time period of stability. That
period for resetting the counter
can not be too short and not too long ... And the periods of absence, the
down/up cycl
Hi Lennart,
When you say "INVALID HANDLE" I assume you mean SA_AIS_ERR_BAD_HANDLE, right ?
/AndersBj
From: elunlen [mailto:elun...@users.sf.net]
Sent: den 10 november 2014 12:54
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] #1179
Acess is available to repl-opensaf on payloads.
At least when I last checked.
In general, services can not assume that they have access to the shared
filesystem on payloads.
So if such access is done (from the service to the shared filesystem at
payoads) it should in priciple
be something that i
Actually, even simpler is just not replying and letting the om-client timeout.
Thew comment even implies that solution.
But is seems not to be what is happening.
/AndersBj
From: Anders Bjornerstedt [mailto:ander...@users.sf.net]
Sent: den 24 oktober 2014 11:49
To:
What output is weird ?
You are invoking an admin-op directly on an implementer.
If this was not intention then be happy about the weird output since it is
telling you that.
It could happen unintentionally because this is a feature added in 4.5 and
beyond the SAF sepc.
/AndersBj
__
But I should also add that a test using a continuous stream of ccbs is a good
stress test of the imm.
The point is only that we dont need to optimize the implementation a lot to
cater for that use case.
/AndersBj
From: Anders Bjornerstedt [mailto:ander...@users.
Ccb outcome (commit/abort) is synced.
This should not be very litle data compared with all the rest.
It is used to redundantly verify the outcome of CCBs.
The nightmre scenario for me would be some state missmatch within the IMMNDs
that resultet
in a CCB getting derailed (and aborted) at one IMMN
Ok!
The log severity in this message:
Sep 2 05:16:57 SLES-SLOT-2 osafimmnd[21492]: WA MESSAGE:81414 OUT OF ORDER my
highest processed:81412, exiting
should be ERror and not WArning. This since immnd exits in the next statement.
I will write a minor ticket on imm for that.
/AndersBj
_
is correct run the xmlint and
immxml-validate on it.
/AndersBj
____
From: Anders Björnerstedt
Sent: den 1 oktober 2014 09:36
To: '[opensaf:tickets] '; opensaf-tickets@lists.sourceforge.net
Subject: RE: [tickets] [opensaf:tickets] #1145 IMM incorrect/irrele
Hi Surender,
My point is this:
The main purpose of the immloader is to load the imm as fast as possible (a
cluster restart is *the* archetypical
high-availability problem, if there is any). If the loading fails due to a
corrupt imm.xml file then the only priority
for the imm-loader is to clearly
Hi Neel,
If you wish you could have a try at fixing this ticket.
Zoran is away for the rest of this week for handling some private things.
/AnersBj
From: Neelakanta Reddy [mailto:neelaka...@users.sf.net]
Sent: den 24 september 2014 15:56
To: opensaf-tickets@list
If this is a case of an NTF callback being invoked towards an NTF client that
does not support longDNs,
yet a long DN pops up from the server, then that should be detected in the NTF
client library and the callback
should not be generated towards the client. If the callback has a return code
(to
Hans, if you update the README again I suggest you re-use/re-classify this
ticket.
/AndersBj
From: Hans Feldt [mailto:hansfe...@users.sf.net]
Sent: den 23 september 2014 11:58
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] #1128 ac
Well thats why I changed it to doc.
I think the only problem was a missunderstanding, hence possibly a need to
clarify the documentation.
Either that or this ticket should be closed with 'worksforme'
/AndersBj
From: Hans Feldt [mailto:hansfe...@users.sf.net]
Sen
The attribute 'accessControlMode' in
'opensafImm=opensafImm,safApp=safImmService' needs to be
updated separately. It is a config attribute.
You have to be a root user to update it.
/AndersBj
From: surender khetavath [mailto:surend...@users.sf.net]
Sent: den 22 s
From: Anders Björnerstedt
Sent: den 18 september 2014 13:41
To: '[opensaf:tickets] '; opensaf-tickets@lists.sourceforge.net
Subject: RE: [tickets] [opensaf:tickets] # AMF: Reject SC swichover
(si-swap) when active ccb modifying amf-data exists
Ticket #1008 is an alternative to t
Ticket #1008 is an alternative to this ticket.
Ticket #1008 could possibly be closed if a fix of this ticket prevents all
cases of a ccb existing
during si-swap that contains ccb-operations on AMF objects.
/AndersBj
From: Nagendra Kumar [mailto:nagendr...@users.
I suggest we hold off testing 2PBE and creating more 2PBE tickets for a while
now.
Many of the already existing tickets probably overlap in their cause.
So we will most likley save time for everyone by fixing these tickets and after
that resume testing.
We are trying to focus on 4.5 also.
/And
Instead of blindly changing other configuration parameters, please first try to
find out what the PROBLEM is.
Go back to OpensAF defaults on all settings, except IMMSV_FEVS_MAX_PENDING
which you had
increased to 255 (the maximum possible).
You said you had "managed to overcome the perormance iss
I dont think they are trimmed from the PBE.
Thewy are trimmed from the special-applier.
/AnersBj
From: Zoran Milinkovic [mailto:zmilinko...@users.sf.net]
Sent: den 15 september 2014 15:30
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:ticket
on
implementer-set as TRY_AGAIN.
As always, a TRY_AGAIN loop must be finite. And implementer-set is not blocked
by imm-sync so we are not
talking 60 secods here. At MOST we are talking sub-second, the fevs turnarround
latency.
/AndersBj
From: Anders
Good analysis.
We can add that the reason that AMFD got BAD_HANLDE when attempting to do an
RtObjectUpdate is that
although the OI handle is valid, it was not associated with any
implementer-name at that time.
So this must be a pure and plain bug in the AMFD. Most likely recently
introduced sin
Hi Sirisha,
sorry for the late answer.
Yes behavior has changed here.
But changes of "behavior" at the level of admin-ownership is something one has
to accept.
I still dont fully understand what this test was trying to do and why.
But even without understanding it, I have explained that the si
Hi Neel,
It is great that you can reproduce it.
This means we should be able to narrow down (binary search) the line of code
where the bug is.
It is not as simple as a logtrace buffer being too small.
The logtrace logic should be truncating the string according to the size of the
buffer.
Pleas
No it has nothing to with delete.
I am writing a mini report in the ticket.
Hold on.
/AndersBj
From: Sirisha Alla [mailto:sirisha.a...@oracle.com]
Sent: den 21 augusti 2014 13:51
To: opensaf-tickets@lists.sourceforge.net
Subject: Re: [tickets] [opensaf:tickets] #1
There is a bug because a duplicate delete should be caught by the immsv and not
reach the PBE.
Probablythe duplicate delete is generated internally by some bug...
/AndersBj
From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
Sent: den 21 augusti 2014 13:0
I am reviewing it right now.
/AndersBj
From: Mathi Naickan [mailto:mathi-naic...@users.sf.net]
Sent: den 13 augusti 2014 14:21
To: opensaf-tickets@lists.sourceforge.net
Subject: [tickets] [opensaf:tickets] #828 IMM utils C++ library
In preparation for 4.5 FC. I
Amazingly some mailbrowsers insisted on "pollishing" the new ticket slogan,
removing the asterisk after char etc.
I get the correct unmolested slogan in firefox, but not in outlook.
/AndersBj
From: Anders Bjornerstedt [mailto:ander...@users.sf.net]
Sent: den 11 ju
Sourceforge ticket system is currently down so just sending this email instead
of updateing ticket.
I hae a problem with the syslogs provided for #855.
Only the syslog provided for PL4 covers the time period of the crash of the
immnd which also occurrs on PL4.
The crash of PL4 is right after the
Agree with this.
You mentioned c++ exceptions.
Lets not start writing code for *catching* exceptions for now, since that can
have quite heavy performance/stack-memory implications.
That means thrown exceptions will be like asserts.
/AndersBj
From: Anders Widell
impossible,
whatecer we decide.
So there is no solution to our created problem.
I hate creating problems that can not be solved.
/AndersBj
From: Anders Björnerstedt [mailto:anders.bjornerst...@ericsson.com]
Sent: den 28 januari 2014 09:28
To: [opensaf:tickets
I have to state that I dont agree with the all encompassing SMF principle that
all objects (including all runtime state) must be recreated
by an SMF rollback.
Runtime data is not directly controlled by SMF but by the OIs, in this case
mainly by the OIs that manage the config objects that
are the
There seems even a risk that the old active IMMD could beexecuting overlapped
with the new active IMMD executing.
Nooo.
:-)
/AndersBj
From: Anders Bjornerstedt [mailto:ander...@users.sf.net]
Sent: den 17 januari 2014 11:42
To: opensaf-tickets@lists.sourceforg
In OpenSAF 4.3 and later.
/AndersBj
From: Anders Björnerstedt
Sent: den 13 december 2013 15:06
To: Anders Björnerstedt; Bertil Engelholm; Ticket 657;
opensaf-tickets@lists.sourceforge.net
Subject: RE: [tickets] [opensaf:tickets] #657 SMF component got faulted
And yes saImmOiClassImplementerSet is idempotent.
/AndersBj
From: Anders Björnerstedt [mailto:anders.bjornerst...@ericsson.com]
Sent: den 13 december 2013 15:04
To: Bertil Engelholm; Ticket 657; opensaf-tickets@lists.sourceforge.net
Subject: Re: [tickets
switchover (si-swap). Thats the only case where it makes more sense to use
implementerClear than finalize/initialize.
But both should normally work.
/AndersBj
From: Bertil Engelholm
Sent: den 13 december 2013 14:56
To: Anders Björnerstedt; Ticket 657; opensaf-tickets
The most likely error code on an implementer-clear would be try-again.
A brutal way to release implementers, which can not "fail" is to just finalize
the OI-handle.
Of course that typically means you also need to initialize a new OI handle if
the process is to continue
as some other implementer/
SA_IMM_ATTR_NO_DUPLICATGES can be upgraded in to an attrtibute defintion for a
multivalued attribute in a class.
But a runtime check is done by the IMM over the class extent that no instance
has duplicates in that attribute.
If any instance has duplicates, the IMM does not try to correct it, inst
Actually for SAF services using a SAF prefix seems to be the norm.
Ticket still valid.
/Anders Bjornerstedt
-Original Message-
From: Anders Björnerstedt [mailto:anders.bjornerst...@ericsson.com]
Sent: den 4 juli 2013 12:52
To: opensaf-de...@lists.sourceforge.net
Cc: opensaf-tickets
of an
OpenSAF
Prefix, although that would break the uniformity of naming in OpenSAF.
/Anders Bjornerstedt
-Original Message-
From: OpenSAF Trac [mailto:t...@devel.opensaf.org]
Sent: den 24 juni 2013 09:06
Cc: Anders Björnerstedt; mathi.naic...@oracle.com;
opensaf-tickets
45 matches
Mail list logo
