Hi Frank,
To elaborate on this (because the context wasn't really explained in the
original mail of Jones):
We found that in performance tests on our product (with a big number of
agents) that there was a high thread contention for SNMPv3 managed
agents. A jstack showed that a lot of our threads were running in the
following stack frame at the moment of the jstack, which indicates that
this functionality generates a relatively big load:
"JM-282" prio=3 tid=0x000000013f032800 nid=0x391 runnable
[0xfffffffc89f38000]
java.lang.Thread.State: RUNNABLE
at sun.security.pkcs11.wrapper.PKCS11.C_DestroyObject(Native Method)
at sun.security.pkcs11.SessionKeyRef.dispose(P11Key.java:1070)
at
sun.security.pkcs11.SessionKeyRef.drainRefQueueBounded(P11Key.java:1046)
at sun.security.pkcs11.SessionKeyRef.<init>(P11Key.java:1061)
at sun.security.pkcs11.P11Key.<init>(P11Key.java:97)
at sun.security.pkcs11.P11Key$P11SecretKey.<init>(P11Key.java:374)
at sun.security.pkcs11.P11Key.secretKey(P11Key.java:266)
at
sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:222)
at
sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:131)
at sun.security.pkcs11.P11Cipher.engineGetKeySize(P11Cipher.java:828)
at javax.crypto.Cipher.b(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
- locked <0xfffffffd81aa1ca8> (a java.lang.Object)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at org.snmp4j.security.PrivDES.encrypt(PrivDES.java:111)
at org.snmp4j.security.USM.generateResponseMessage(USM.java:461)
at org.snmp4j.security.USM.generateRequestMessage(USM.java:215)
at org.snmp4j.mp.MPv3.prepareOutgoingMessage(MPv3.java:767)
at
org.snmp4j.MessageDispatcherImpl.sendPdu(MessageDispatcherImpl.java:444)
at org.snmp4j.Snmp.sendMessage(Snmp.java:1067)
at org.snmp4j.Snmp.send(Snmp.java:895)
- locked <0xfffffffd81aa2068> (a org.snmp4j.Snmp$SyncResponseListener)
at org.snmp4j.Snmp.send(Snmp.java:875)
Originally, our performance team pointed in the direction of SNMP4J,
saying that SNMP4J should probably not call Cipher.init() so much, but I
could show them that section 8.1.1.1 in RFC 2574 requires to init the
Cipher for each packet separately.
So then we started looking at alternatives, and we found that if we
hacked SNMP4J to use the Apache BouncyCastle security provider, the
thread contention was gone and our application behaved properly. So
presumably the Sun JCE security provider that is used by default by
SNMP4J is not very optimally written.
Now, we would not like to have to maintain our own patch on SNMP4J, so
that is where the question from Jones came from: we tried to change the
default security provider that SNMP4J uses without touching SNMP4J's
code, but Security.insertProviderAt() apparently doesn't help in that
even if we insert the provider at position 0.
Could an API be added to permit applications to change the security
provider that SNMP4J uses?
Best regards,
Peter.
On 24/10/2011 9:00, jones vinu wrote:
> Hi Frank,
> We would want to change the Cipher encryption provider in our
> application used by snmp4j since the Sun JCE provider is heavy weight . But
> unfortunately we have not been able to change it without modifying snmp4j
> since the Sun JCE provider is considered as the default provider even when we
> insert Apache bouncy castle as the first priority provider. Hence it would
> be good if we have option to configure the provider as a Configurable
> parameter in some property file.
>
> Security.insertProviderAt(new BouncyCastleProvider(), 0);
> try {
> Cipher alg = Cipher.getInstance("DESede/CBC/NoPadding");
> System.out.println(alg.getProvider());
> } catch (NoSuchAlgorithmException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (NoSuchPaddingException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> Output :SunJCE version 1.6
>
> And using it as
> Cipher alg = Cipher.getInstance("DESede/CBC/NoPadding","BC");
> Output :BC version 1.4
>
> Thanks
> Jones
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J@agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
--
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV
_______________________________________________
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
