Hello Christian, There is indeed a bug in AgentXSubagent class (SFJ-65) which overwrites the shared table support with an instance created by the AgentXSubagent class through its createSharedTableSupport method.
That is also the method you could overwrite to effectively set a custom AgentXSharedTableSupport instance. I have fixed the AgentXSubagent.registerRegions and registerSharedRows methods to use and not overwrite any shared table support instances of the AgentXSharedMutableMOTables. The testing was OK, because I modified the shared table support during runtime and unfortunately did not check its behavior during startup. I need further testing before releasing a new versions, but you may try it by downloading the latest snapshot. Best regards, Frank Am 01.10.2012 12:02, schrieb HAAS Christian: > Hello again! > > Months later I've been assigned again to this topic - and still struggle with > the solution. (I've included the complete conversation below.) > > For a start, I've switched the dependency of snmp4j from 1.10.2 to 2.1.0, > which includes your extension code. > > First I was struggling with getting the new > IndexStrategy.anyNonAllocatedSubIndex into the DefaultAgentXSharedMOTable. > Because at construction time, this one doesn't have a > AgentXSharedMOTableSupport object set - and setting one doesn't seem to be > helpful either, because AgentXSubagent.registerRegions() creates a new object > and directly sets it - right before the call to > AgentXSubagent.registerSharedTableRows(). > Since I found no way to access or modify the table support, I created an > extension of DefaultAgentXSharedMOTable which overwrites > setAgentXSharedMOTableSupport() and sets the IndexStrategy on the passed > object before passing it on to super. > > I don't think that this is the proper way, but couldn't see any other. At > least this then worked for the first process to let it fill in its first rows > with combined keys. > > > But starting the second process that wanted to extend this table further > failed again; The response code in AgentXSharedMOTableSupport.allocateIndex() > was 260. Is this the problem you mentioned that NetSNMP itself can't work > with combined keys? > > > As a cross test, I left the first process running and switched the > IndexStrategy to IndexStrategy.anyNonAllocatedSubIndex . This one would be > accepted by NetSNMP, but causes then an InvalidArgumentException in > MOTableIndex.getIndexOID(), called from > AgentXSharedMOTableSupport.allocateIndex(), while handling the response. The > reason here is that the index has two entries, but allocateIndex() had the > vbs variable reset to be an array of size 1 just before (in the switch for > the strategy). > (This exception was also thrown when I was using all the default code, i.e. > no overriding of setAgentXSharedMOTableSupport() ) > > > I'm sorry, but I'm still lost about how to use this. Do you have any advice > what I should change? > > Kind regards, > ch > ____________________________________________________ > Christian Haas > Software Engineer > FREQUENTIS AG > > Innovationsstraße 1, 1100 Vienna, Austria > Phone +43-1-811 50 – 8353 > Mobile +43-664-60 850 – 8353 > Fax +43-1-811 50 – 77 8353 > Web www.frequentis.com > E-Mail christian.h...@frequentis.com > > Handelsgericht Wien (Vienna Commercial Court): FN 72115 b > DVR 0364797, ATU 14715600 > ____________________________________________________ > Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen > enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser E-Mail sind nicht gestattet. > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorised > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. > > -----Original Message----- > From: snmp4j-boun...@agentpp.org [mailto:snmp4j-boun...@agentpp.org] On > Behalf Of Frank Fock > Sent: Montag, 05. März 2012 17:23 > To: snmp4j@agentpp.org > Subject: Re: [SNMP4J] Filling a shared table with two index columns from > several processes not working > > Hi, > > will post a link to the SNAPSHOT sources here once, > I have finished the implementation. > I am currently extending the test subagent to be able > to test and illustrate the behaviors. > > Mostr likely, the AgentXSharedTableSupport class > will be extended to support four index allocation > strategies. The default one, will be suitable for > most use cases then (including master/child table). > > Thus, API users will not have to change their code > in most cases. > > Best regards, > Frank > > Am 05.03.2012 14:26, schrieb HAAS Christian: >> Hello there! >> >> From: snmp4j-boun...@agentpp.org [mailto:snmp4j-boun...@agentpp.org] On >> Behalf Of Frank Fock >>> You are facing the same issue as described in >>> http://lists.agentpp.org/pipermail/snmp4j/2012-March/004789.html >>> >>> I understand that this situation is not covered userfriendly by >>> SNMP4J-AgentX as implementing a subclass is not straight forward. >>> >>> I will provide such a subclass of AgentXSharedMOTableSupport for multi >>> variable indexes and master/child tables within the next few days. >> Thank you, Frank, for this answer. Where will I be able to find this >> implementation? Because in my case, I have no idea what specific handling >> would be required, as suggested for this subclass. >> >> Kind regards, >> ch >> >> >> >> Am 02.03.2012 08:26, schrieb HAAS Christian: >>> Hello there! >>> >>> I have one of those "Hardly an understanding of the underlying system, but >>> have to make it work" cases and I hope to find the right pointers here. >>> >>> Setup and Goal: >>> We are using SNMP4J together with Net-SNMP for our processes. On a host >>> with Net-SNMP, we have several of our processes running and each of them >>> shall report some internal statistics (e.g. amount of threads) into a >>> shared table. >>> >>> This table has an index consisting of two columns: The unique process >>> (component) ID and the statistics (entry) ID. >>> The idea is to access such a statistics row by using an OID >>> table.componentId.entryId >>> >>> Several of the entry IDs are reported by more than one process, some are >>> reported by only a selected few - still, each in his own row though. All >>> rows of ones own componentId are handled by the respective process. >>> For example: >>> table.componentA.numberOfThreads = ... >>> table.componentA.packetsReceived = ... >>> table.componentB.numberOfThreads = ... >>> table.componentB.packetsReceved = ... >>> table.componentB.numberOfSessions = ... >>> >>> >>> The Problem(s): >>> Filling in the expected values for the index data, each process can >>> add at most one row. (Typically, only one row would show up as for >>> second problem) Filling a unique 'counter' value into the componentId lets >>> the processes add specific entries only once (e.g. only one is to report >>> numberOfThreads; The first process to register reports all his entries, any >>> further reports only those entryIds not yet used) Filling unique counters >>> for both index fields, all processes can add all data. >>> >>> But the second two are probably not what is expected when reading the MIB. >>> The intent is to use the indexDef as a combined primary key, but as it >>> appears, the two are handled being primary keys each on their own. >>> >>> MIB: >>> -- 1.3.6.1.4.1.3043.6.7.2.52 >>> frqChNvpTable OBJECT-TYPE >>> SYNTAX SEQUENCE OF FrqChNvpEntry >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "Name-value-pairs" >>> ::= { frqComponentHealthObjects 52 } >>> >>> >>> -- 1.3.6.1.4.1.3043.6.7.2.52.1 >>> frqChNvpEntry OBJECT-TYPE >>> SYNTAX FrqChNvpEntry >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "Name-value-pair" >>> INDEX { chNvpComponentId, chNvpEntryId } >>> ::= { frqChNvpTable 1 } >>> >>> >>> FrqChNvpEntry ::= >>> SEQUENCE { >>> chNvpComponentId >>> INTEGER, >>> chNvpComponentName >>> DisplayString, >>> chNvpEntryId >>> INTEGER, >>> chNvpEntryName >>> DisplayString, >>> chNvpEntryLongName >>> DisplayString, >>> chNvpEntryValueType >>> INTEGER, >>> chNvpEntryValueInt >>> Integer32, >>> chNvpEntryValueString >>> OCTET STRING >>> } >>> >>> >>> Code: >>> In code, a DefaultAgentXSharedMOTable is used, with the indexDef set up >>> hopefully right: >>> >>> { // setup combined index >>> /** Sub indexes (SNMP)*/ >>> final MOTableSubIndex[] subIndexes = new MOTableSubIndex[2]; >>> >>> subIndexes[0] = >>> new MOTableSubIndex( new OID( >>> MOTableBuilder.OID_CH_NVP_TABLE ) >>> .append( >>> MOTableBuilder.MO_COLUMN_IDX_CH_NVP_COMPONENT_ID ), >>> SMIConstants.SYNTAX_INTEGER, 1, 1 ); >>> subIndexes[1] = >>> new MOTableSubIndex( new OID( >>> MOTableBuilder.OID_CH_NVP_TABLE ) >>> .append( >>> MOTableBuilder.MO_COLUMN_IDX_CH_NVP_ENTRY_ID ), >>> SMIConstants.SYNTAX_INTEGER, 1, 1 ); >>> this.indexDef = new MOTableIndex( subIndexes ); >>> } >>> >>> >>> Questions: >>> 1. Is the basic goal possible at all? If not, I can save some problem >>> finding and we need to go back to the drawing board. >>> 2. If possible, what am I doing wrong in the code? How should I do it? >>> 3. Is there anything more I should provide so I can help you help me >>> help us all? :) 4. Side question: What are the two last parameters of the >>> MOTableSubIndex constructor for? It works only using 1, 1. >>> >>> I realize just days ago there seems like to have been a similar problem >>> with a combined index on this list, but I can't see whether this is the >>> same problem nor did I understand the proposed solution. >>> >>> Thank you and kind regards, >>> ch >>> ____________________________________________________ >>> Christian Haas >>> Software Engineer >>> FREQUENTIS AG >>> >>> Innovationsstraße 1, 1100 Vienna, Austria >>> Phone +43-1-811 50 - 8353 >>> Mobile +43-664-60 850 - 8353 >>> Fax +43-1-811 50 - 77 8353 >>> Web www.frequentis.com >>> E-Mail >>> christian.h...@frequentis.com<mailto:christian.h...@frequentis.com> >>> >>> Handelsgericht Wien (Vienna Commercial Court): FN 72115 b DVR 0364797, >>> ATU 14715600 ____________________________________________________ >>> Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte >>> Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder >>> diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den >>> Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die >>> unbefugte Weitergabe dieser E-Mail sind nicht gestattet. >>> This e-mail may contain confidential and/or privileged information. If you >>> are not the intended recipient (or have received this e-mail in error) >>> please notify the sender immediately and destroy this e-mail. Any >>> unauthorised copying, disclosure or distribution of the material in this >>> e-mail is strictly forbidden. >>> >>> >>> >>> _______________________________________________ >>> SNMP4J mailing list >>> SNMP4J@agentpp.org >>> http://lists.agentpp.org/mailman/listinfo/snmp4j >> -- >> --- >> AGENT++ >> Maximilian-Kolbe-Str. 10 >> 73257 Koengen, Germany >> https://agentpp.com >> Phone: +49 7024 8688230 >> Fax: +49 7024 8688231 >> >> _______________________________________________ >> SNMP4J mailing list >> SNMP4J@agentpp.org >> http://lists.agentpp.org/mailman/listinfo/snmp4j >> _______________________________________________ >> SNMP4J mailing list >> SNMP4J@agentpp.org >> http://lists.agentpp.org/mailman/listinfo/snmp4j -- --- AGENT++ Maximilian-Kolbe-Str. 10 73257 Koengen, Germany https://agentpp.com Phone: +49 7024 8688230 Fax: +49 7024 8688231 _______________________________________________ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
