powered by Jive Software

XMPPConnection closed due to an exception (0)

15:52:43.069 2618-2919/com.techsbiz.apnaapp D/SMACK: XMPPConnection closed due to an exception (0)
04-20 15:52:43.069 2618-2919/com.techsbiz.apnaapp W/System.err: java.lang.IllegalArgumentException: id must not be null
at org.jivesoftware.smack.util.StringUtils.requireNotNullOrEmpty(StringUtils.java:263)
at org.jivesoftware.smackx.receipts.DeliveryReceipt.(DeliveryReceipt.java:46)
at org.jivesoftware.smackx.receipts.DeliveryReceipt$Provider.createReturnExtension(DeliveryReceipt.java:107)
at org.jivesoftware.smackx.receipts.DeliveryReceipt$Provider.createReturnExtension(DeliveryReceipt.java:100)
04-20 15:52:43.070 2618-2919/com.techsbiz.apnaapp W/System.err: at org.jivesoftware.smack.provider.EmbeddedExtensionProvider.parse(EmbeddedExtensionProvider.java:108)
at org.jivesoftware.smack.provider.EmbeddedExtensionProvider.parse(EmbeddedExtensionProvider.java:84)
at org.jivesoftware.smack.provider.Provider.parse(Provider.java:35)
at org.jivesoftware.smack.util.PacketParserUtils.parseExtensionElement(PacketParserUtils.java:929)
at org.jivesoftware.smack.util.PacketParserUtils.addExtensionElement(PacketParserUtils.java:1060)
at org.jivesoftware.smack.util.PacketParserUtils.parseMessage(PacketParserUtils.java:287)
at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(PacketParserUtils.java:151)
at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessStanza(AbstractXMPPConnection.java:955)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$500(XMPPTCPConnection.java:140)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1001)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:956)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:971)
at java.lang.Thread.run(Thread.java:761)

It seems like the application which sent the delivery receipt did not add an id.
By the look of things, XEP-0184 does not require an ID, so this is probably to be considered a bug in Smack.
I created SMACK-815 to track this issue.

But, this comes from the same client i am creating, and i am not sending auto-delivery receipts, but still i am getting these, instead of Delivery receipts(internal), i am adding a custom extension and sending that with the message packet.
So, how do i stop them coming up.

using this code to added extension
DefaultExtensionElement extRequest = new DefaultExtensionElement(
“request”, “urn:xmpp:receipts”);

I’m not quite getting this part. So instead of using Smacks provided delivery receipts code, you are creating your own request elements? What is the point of this?

Are you also generating your own received elements thst way?

because, we have an iOS client app, that sends us the packet that way, and that client usage XMPP Framework as their library, so to make both project/platform work each other, i need to do it that way only
Are you also generating your own received elements thst way?
and i am even doing the same stuff for read also

Ehm, XMPP is designed to be interoperable. XEP-0184 is also standardized, so actually Smack and XMPP Framework for IOS should work together. If not, you should find out why and report the differences to the authors of the framework. It sounds like the iOS framework does not stick to the standard.

You should not have to create the elements yourselves. As I said, there is a bug in Smack that causes your crash and that needs to be fixed.

As a temporary workaround you could try to disable the ReceiptsProvider and create your own replacement.
@Flow should be able to tell you more about that.

I created #234, which should fix this problem.

but the problem is, i am on smack 4.1.8, i cannot update to latest

Afaik it should be possible to create your own provider and element classes and to register them replacing smacks classes. I’m not sure about the exact way of doing this though. However, that might be a suitable workaround for you.

Does the request message include an id?

See the XEP.

my proposed workaround for you would be:

  • make a copy of the receipts classes
  • apply my fixes from the PR I created to the copy you made
  • call ProviderManager.removeExtensionProvider() for all extension providers in the original receipts package
  • call ProviderManager.addExtensionProvider() for the modified providers in your copied package.
  • use the classes in the copied package instead

I didn’t mean from the XEP point of view, but from death code’s implementation.
Maybe he does not include an id in the requesting message, so that the receipt has none, too.

@CSH from my point of view, i have two kind of delivery receipts, one is autogenerated with difference message is, and receipt it, and the one that i generate by adding default extension,
and this thing was working correctly when i was not on smack 4.1.8,since the version change i am facing this thing.
In version 4.1.2 i think, this thing was working like charm, and as soon as i upgraded to 4.1.8 because of reconnection manager i am seeing this crash

@Paul_Schaub and @CSH the thing i was doing wrong, is i also enabled the auto delivery receipts also using Delivery Manager, so now I have remove the below piece of code
DeliveryReceiptManager dm = DeliveryReceiptManager
dm.addReceiptReceivedListener(new ReceiptReceivedListener() {
public void onReceiptReceived(Jid fromJid, Jid toJid, String receiptId, Stanza receipt) {
and i hope it will work fine

No it didn’t worked, and i even updated the library to 4.2.4 now

I had the same problem (in 4.2.3 and 4.2.4 as well). It seems to be fixed in 4.3.0-rc1 so you might want to wait for the next release

This is SMACK-815 and fixed in 4.3. And I don’t think you should wait for the official release, if everybody did that, the release candidates would be useless, right? :slight_smile:

Yes but is it suitable for production use ?

Depends on what you think qualifies as “production ready”.

If you believe that a release which got its ‘-rc’ stripped is more somehow more production ready then a release candidate, then I have to disappoint you. The only difference is that after a version has been a while in -rc status, and I there have been brought not major bugs to my attention, then I’ll eventually decide that its time for the release.

So yes, a release had more time to mature then a release candidate. But if nobody picks up the release candidate, at least in their staging environment, then the meaningfulness of a release compared to a release candidate is zero.