[SNMP4J] Frank - Need help Urgent!!!!!!

[Frank Fock]

Hello Ignacio,

GETBULK performs GETNEXT like operations on the agent. Thus,
the time to get 22 rows with GETBULK is RTT + 22 TP. Compared
with a 22 thread approach, the GETBULK saves resources like memory
(manager side), CPU time (on manager and agent side), and bandwith.

Why Java 1.4 behaves differently than 1.5 might be caused by different
threading implementations.

Best regards,
Frank

ignacio.izaga at hp.com wrote:

>Hello Frank,
>
>I am currently involved in the project with Eva (but working on a
>different component) and I can provide some information.
>
>I am not sure how Eva is destroying the threads. However, I know why she
>might not be using the GETBULK request.
>
>Eva mentioned that performance is a high priority requirement in the
>application. My understanding is that the GETBULK mechanism is performing
>a GETNEXT iteration. The time it would take to perform "22 getnext" would
>be 22(RTT + Tp) where RTT is the round-trip time and Tp is the Time it
>takes the SNMP agent in the printer to process each the snmp request.
>
>If the RTT is similar to the Tp, then it makes sense to perform 22
>GETNEXT. However, if the RTT is >> than the Tp, it makes sense to create
>22 threads and send each thread after a certain delay (usually Tp). The
>time it would take to perform the 22 requests in this case would be RTT +
>22*Tp. This is why I think Eva is working with the 22 threads approach.
>
>Do you see a faster way to perform the 22 requests? In addition, why is
>Java 1.4 behaving different than 1.5? I have tested the application by my
>self and it is quite easy to hang the sw on 1.4 but not on 1.5.
>
>Thanks again,
>
>Ignacio
>
>
>
>
>_______________________________________________
>SNMP4J mailing list
>SNMP4J at agentpp.org
>http://lists.agentpp.org/mailman/listinfo/snmp4j
>
>
>  
>


-- 
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com