And apologies for not posting correct... it was my first post.
No need for apologies, just wanted to share my thoughts.
And yes, the server does advertise the stream feature for SM... it just doesn't seem to come in service discovery as I expected it to.
SM is never announced via service discovery as it's a stream feature.
It looks like client apps need to do this in order to enable stream management. Is this assumption correct or have I missed something?
No, this should not be the case. SmackTcpSmackInitializer takes care of that.
The variable 'unacknowledgedStanzas' does seem to be initialised correctly but in my instance it seems to not be initialised due to a missing StreamFeatureProvider for 'urn:xmpp:sm:3'
I don't think the assumption that it's caused by the StreamManagedStreamFeatureProvider not being registered is correct. Because if the Provider is not registered then isSmAvailable() will never return true, which will prevent XMPPTCPConnection from enabling StreamManagement, but then the server should/would not send a Resumed element, which causes to processHandledCount() from being invoked where the NPE happens.
But it's conceivable that the server sends Resumed elements while SM is not active (for whatever reason). Could you verify this by enabling SmackConfiguration.DEBUG? Show us a complete XMPP trace from an example session, maybe we see how the client *does not* enable SM, but the server is nevertheless sending a Resumed element. Which server do you use?