Tigase XMPP Server Board

Tigase server development: Problem with Stream Management

Wed, 02/25/2015 - 06:15

Hi there,

i am trying to make stream management work, testing this scenario

  • a client connected with stream management on, on a mobile phone
  • tigase server 7.0.0 with stream management on
  • the client is connected to the server
  • I set the mobile in airplane mode
  • I send a message to the client

in the log I find that the message (together with presence/IQ/...) arrives to the server, and I get the resumption timeout check in place...

2015-02-25 11:32:16.446 [socketReadThread-8] StreamManagementIOProcessor.serviceStopped() FINEST: c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322, type: accept, Socket: TLS: c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322 Socket[unconnected], jid: 103@acme.domain.net/MyResource, service stopped - checking resumption timeout

After a while it looks like the stream gets closed (I see many messages saying that)

2015-02-25 11:32:51.313 [scheduler_pool-6-thread-1-c2s] ClientConnectionManager.xmppStreamClosed() FINE: Service stopped, sending packet: from=c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322, to=sess-man@acme.domain.net, DATA=<iq type="set" from="c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322" to="sess-man@acme.domain.net" id="c4502e14-0454-4f0b-9144-f0327b94b5b0"><command node="STREAM_CLOSED" xmlns="http://jabber.org/protocol/commands"><x type="submit" xmlns="jabber:x:data"><field var="user-jid"><value>103@acme.domain.net/MyResource</value></field></x></command></iq>, SIZE=375, XMLNS=null, PRIORITY=SYSTEM, PERMISSION=NONE, TYPE=set 2015-02-25 11:32:51.313 [in_3-message-router] MessageRouter.processPacket() FINEST: Processing packet: from=103@acme.domain.net/MyResource, to=acme.domain.net, DATA=<iq type="error" from="103@acme.domain.net/MyResource" to="acme.domain.net" id="tigase-ping"><ping xmlns="urn:xmpp:ping"/><error code="404" type="wait"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>, SIZE=244, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=error 2015-02-25 11:32:51.313 [in_5-message-router] MessageRouter.processPacket() FINEST: Processing packet: from=c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322, to=sess-man@acme.domain.net, DATA=<iq type="set" from="c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322" to="sess-man@acme.domain.net" id="c4502e14-0454-4f0b-9144-f0327b94b5b0"><command node="STREAM_CLOSED" xmlns="http://jabber.org/protocol/commands"><x type="submit" xmlns="jabber:x:data"><field var="user-jid"><value>103@acme.domain.net/MyResource</value></field></x></command></iq>, SIZE=375, XMLNS=null, PRIORITY=SYSTEM, PERMISSION=NONE, TYPE=set 2015-02-25 11:32:51.314 [session-close Queue Worker 3] SessionManager$SessionCloseProc.process() FINEST: Executing connection close for: from=c2s@acme.domain.net/172.31.30.109_5222_10.0.0.1_49322, to=sess-man@other.domain.net, DATA=<iq type="set" from="c2s@other.domain.net/172.31.30.109_5222_10.0.0.1_49322" to="sess-man@other.domain.net" id="c4502e14-0454-4f0b-9144-f0327b94b5b0"><command node="STREAM_CLOSED" xmlns="http://jabber.org/protocol/commands"><x type="submit" xmlns="jabber:x:data"><field var="user-jid"><value>103@acme.domain.net/MyResource</value></field></x></command></iq>, SIZE=375, XMLNS=null, PRIORITY=SYSTEM, PERMISSION=NONE, TYPE=set 2015-02-25 11:32:51.315 [session-close Queue Worker 3] SessionManager.closeSession() FINE: Closing connection for: 103@acme.domain.net/MyResource 2015-02-25 11:32:51.315 [session-close Queue Worker 3] SessionManager.closeSession() FINE: Found parent session for: 103@acme.domain.net/MyResource

But at a certain point we get the weird thing:

2015-02-25 11:32:51.315 [in_7-sess-man] SessionManager.processPacket() FINEST: processing packet: from=103@acme.domain.net/MyResource, to=sess-man@other.domain.net, DATA=<iq type="error" from="103@acme.domain.net/MyResource" to="acme.domain.net" id="tigase-ping"><ping xmlns="urn:xmpp:ping"/><error code="404" type="wait"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>, SIZE=244, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=error, connection: XMPPResourceConnection=[user_jid=sess-man@other.domain.net, packets=18, connectioId=null, domain=other.domain.net, authState=NOT_AUTHORIZED, isAnon=false, isTmp=false] 2015-02-25 11:32:51.315 [in_7-sess-man] SessionManager.walk() FINEST: XMPPProcessorIfc: UrnXmppPing (urn:xmpp:ping)Request: from=103@acme.domain.net/MyResource, to=sess-man@other.domain.net, DATA=<iq type="error" from="103@acme.domain.net/MyResource" to="acme.domain.net" id="tigase-ping"><ping xmlns="urn:xmpp:ping"/><error code="404" type="wait"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>, SIZE=244, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=error, conn: XMPPResourceConnection=[user_jid=sess-man@other.domain.net, packets=19, connectioId=null, domain=other.domain.net, authState=NOT_AUTHORIZED, isAnon=false, isTmp=false] 2015-02-25 11:32:51.316 [in_7-sess-man] SessionManager.processPacket() INFO: Impossible happened, please report to developer packet: from=103@acme.domain.net/MyResource, to=sess-man@other.domain.net, DATA=<iq type="error" from="103@acme.domain.net/MyResource" to="acme.domain.net" id="tigase-ping"><ping xmlns="urn:xmpp:ping"/><error code="404" type="wait"><recipient-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>, SIZE=244, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=error, connection: XMPPResourceConnection=[user_jid=sess-man@other.domain.net, packets=19, connectioId=null, domain=other.domain.net, authState=NOT_AUTHORIZED, isAnon=false, isTmp=false].

If you notice, the connection close is sent by another subdomain (other.domain.net). Is this OK / expected ?

the IQ stanza with the STREAM_CLOSE arrives to the session manager, but, surprise surprise, I get a message with "Impossible happened"... (may I humbly request to consider changing this message ? after two hours of debug, you can expect everything, but "impossible happened" is a little too much to digest ! :) )

Apart from the message, do you see anything wrong, but most of all, can you understand what is happening ? Everything because, sadly, when resumption_timeout passes, messages aren't neither persisted on database nor delivered if the client reconnects. Am I doing something wrong ? I'd be glad to find out so, or even find out that there is a problem that I can help fixing (as I always say to myself, we all love open source for that ! )

Thanks in advance,
Luca

Categories: Tigase Forums

Tigase server administration: Reconnecting service for component

Wed, 02/25/2015 - 05:52

Hi,
as I run tigase 7.1.0-Snapshot, in the log I got these lines:
2015-02-25 17:17:51.956 [scheduler_pool-4-thread-1-c2s] ConnectionManager$1.run() FINE: Reconnecting service for component: c2s, to remote host: localhost on port: 5222 2015-02-25 17:17:51.957 [scheduler_pool-4-thread-1-c2s] ConnectionManager$1.run() FINE: Reconnecting service for component: c2s, to remote host: localhost on port: 5223 2015-02-25 17:17:51.962 [scheduler_pool-11-thread-1-s2s] ConnectionManager$1.run() FINE: Reconnecting service for component: s2s, to remote host: localhost on port: 5269 2015-02-25 17:17:51.964 [scheduler_pool-3-thread-1-bosh] ConnectionManager$1.run() FINE: Reconnecting service for component: bosh, to remote host: localhost on port: 5280 2015-02-25 17:17:51.964 [scheduler_pool-15-thread-1-ws2s] ConnectionManager$1.run() FINE: Reconnecting service for component: ws2s, to remote host: localhost on port: 5290 2015-02-25 17:17:51.964 [scheduler_pool-3-thread-1-bosh] ConnectionManager$1.run() FINE: Reconnecting service for component: bosh, to remote host: localhost on port: 5281
I want to know why tigase try to connect to these services in local host (I haven't any remote service and run tigase in a single node)?

the only special configuration I have is:
--bosh-ports = 5280,5281
bosh/connections/5281/socket = ssl
bosh/connections/5281/type = accept

Categories: Tigase Forums

Tigase server administration: RE: No reply from MUC when try to configure a Reserved Room

Wed, 02/25/2015 - 04:30

Hamid Alimohammadi wrote:

When owner of a room try to change the default setting of a room (to make it Persistent, etc), we follow the XEP-0045 instructions and server responds to the Stanzas properly until the section that "Owner Submits Configuration Form": [[http://xmpp.org/extensions/xep-0045.html#example-159]]
Then the room owner fill out the bellow form accordingly and submit it to the service:
(The name of room is "testroom" and the owner is )

Actually you've made a mistake in your query - you are sending a dataform of type form (which was received from server) instead of type submit (to, well, submit the form) as the specification requires.
<x xmlns='jabber:x:data' type='form'>
should be changed to
<x xmlns='jabber:x:data' type='submit'>

Categories: Tigase Forums

Tigase server administration: RE: No reply from MUC when try to configure a Reserved Room

Wed, 02/25/2015 - 02:39

Actually there was not there anything afterwards. Today I tried with another version (7.0.0-b3802), the last logfile line is like above log:
ModulesManager.process() FINEST: Finished class tigase.muc.modules.RoomConfigurationModule

And no more message is received. I run the XML with Psi XML console and my colleague with gloox, camaya.

Thanks again for help

Categories: Tigase Forums

Tigase server development: RE: Client timeout?

Wed, 02/25/2015 - 00:55

Wojciech Kapcia wrote:

Handling of such connections and prevention of loosing messages on dropped connections was greatly improved in current development version - 7.0.0, which should be released soon.

I tried the relesed version - 7.0.0,feeling it has no improvement,when I turn off wifi, annother user also find it is online

and thne I tried use this configuration:

c2s/processors[s]=urn:xmpp:sm:3
c2s/watchdog_delay[L]=60000
c2s/watchdog_timeout[L]=60000
c2s/max-inactivity-time[L]=60
c2s/watchdog_ping_type=xmpp

all user connections broken

Categories: Tigase Forums

Tigase server administration: RE: No reply from MUC when try to configure a Reserved Room

Tue, 02/24/2015 - 23:06

Hamid Alimohammadi wrote:

Thank you for reply.
I enabled --debug=muc,component,component2 and bellow is the Tigase.log.0 file readouts:
Could you please take a look at logs to see if anything is wrong?
---------------------------------------------------------------------------------------
[...]

Actually you've cut the logs right in the middle of processing. Or wasn't there anything afterwards?

Categories: Tigase Forums

Tigase server administration: RE: How to enable only particular level of logs?

Tue, 02/24/2015 - 22:51

Igor Khomenko wrote:

Is there a full documentation somewhere in Tigase Administration guide? If not - would be great to add

Unfortunately it's not explicitly documented for the moment. We are constantly improving docs so it will definitely be added :-)

Another question - is there an explanation of all log levels? where to use FINE, where INFO etc

They follow Java's Logger Level. The difference is simply detail of created logs. In principle everything above FINE (inclusive) will produce quite detailed debug with lots of information about processing of each packet.

Categories: Tigase Forums

Tigase server administration: RE: It's not possible to login with some xmpp clients - Tigase 7.0.0

Tue, 02/24/2015 - 22:48

Gianluca Lorenzin wrote:

Ok, but with Tigase 5.2.3 we could connect without problems; there is something new on Tigase 7.0.0 regarding this aspect of implementation?

As I said - this change was introduced in the version 7.0.0 therefore the difference.

Gianluca Lorenzin wrote:

I saw related issue #2781 and I try to add: [...] to init.properties but nothing changes...

This property was added shortly after 7.0.0 release. It will be available shortly in the next minor release to deal with the clients that break the specification.

Categories: Tigase Forums

Tigase server development: RE: NullPointerException in StreamManagementIOProcessor when trying to...

Tue, 02/24/2015 - 20:38

It is really hard to advise you on impact because code change between these 2 versions is significant in all areas, lots of improvements and fixes. If you need a help with upgrading your code to version 7.0.0, let us know. We can help.

Categories: Tigase Forums

Tigase server development: RE: NullPointerException in StreamManagementIOProcessor when trying to...

Tue, 02/24/2015 - 20:33

I see... I'm using StreamManagementIOProcessor in this commit : https://projects.tigase.org/projects/tigase-server/repository/revisions/f8c9d4dd78a7d9b4b1a5ecabd002cf7bea817d61/entry/src/main/java/tigase/server/xmppclient/StreamManagementIOProcessor.java

Upgrading to 7.0.0 will still take some time for us, as we've done some modification base on 5.2.0, the above code would be as temp fix, just want to know if there are any impacts.

Thanks :)

Categories: Tigase Forums

Tigase server development: RE: NullPointerException in StreamManagementIOProcessor when trying to...

Tue, 02/24/2015 - 20:15

What do you mean by "latest"? I have seen this NPE in the stream management code and as far as I remember it has been already fixed. There was a lot of changes in the stream management code between version 5.2.0 and 7.0.0, so I cannot guarantee that it will work if you just pick one class. On the other hand, I did not code this part of the server so I might be wrong.

Categories: Tigase Forums

Tigase server development: NullPointerException in StreamManagementIOProcessor when trying to rem...

Tue, 02/24/2015 - 18:12

Hi devs,

We're using Tigase 5.2.0 but cherry-picked the latest StreamManagementIOProcessor class and we ran into this exception:

2015-02-24 15:10:20.370 [Watchdog - c2s] ThreadExceptionHandler.uncaughtException() SEVERE: Uncaught thread: "Watchdog - c2s" exception java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:333) at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1186) at tigase.server.xmppclient.StreamManagementIOProcessor.serviceStopped(StreamManagementIOProcessor.java:368) at tigase.xmpp.XMPPIOService.forceStop(XMPPIOService.java:257) at tigase.net.IOService.stop(IOService.java:476) at tigase.xmpp.XMPPIOService.stop(XMPPIOService.java:315) at tigase.server.ConnectionManager$Watchdog$1.check(ConnectionManager.java:1547) at tigase.server.ConnectionManager.doForAllServices(ConnectionManager.java:1008) at tigase.server.ConnectionManager$Watchdog.run(ConnectionManager.java:1509) at java.lang.Thread.run(Thread.java:744)

Is it safe to do a null checking on id? If id is null then we'll do nothing.

--- a/src/main/java/tigase/server/xmppclient/StreamManagementIOProcessor.java +++ b/src/main/java/tigase/server/xmppclient/StreamManagementIOProcessor.java @@ -365,6 +365,10 @@ public class StreamManagementIOProcessor implements XMPPIOProcessor { if ((System.currentTimeMillis() - resumptionTimeoutStart) > (2 * resumption_timeout * 1000)) { // if so we should assume that resumption failed so we should // send errors, remove reference to service and stop this service + if (id == null) { + log.log(Level.WARNING, " attempting to remove serive, but id is null, abort"); + return false; + } services.remove(id, service); service.clearWaitingPackets(); connectionManager.serviceStopped(service);
Categories: Tigase Forums

Tigase server development: RE: EventBus documentation

Tue, 02/24/2015 - 09:18

Sounds like a killer feature)
looking forward for documentation

Categories: Tigase Forums

Tigase server development: RE: EventBus documentation

Tue, 02/24/2015 - 09:14

We are working on documentation and example code for all new elements. In summary, this is kind of a PubSub inside the Tigase core code. All the Tigase components and plugins can publish stuff to this PubSub nodes and any other components or even XMPP entities can subscribe to receive notifications form these nodes. This opens whole new applications and ways the Tigase can be extended, monitored and interact with... "the whole world" :-)

Categories: Tigase Forums

Tigase server development: EventBus documentation

Tue, 02/24/2015 - 09:09

Checked this post and found an info about EventBus http://www.tigase.net/blog-entry/tigase-server-700-release

Is there some documentation or some explanation what is this and how people can use it?

Thanks

Categories: Tigase Forums

Tigase server administration: RE: It's not possible to login with some xmpp clients - Tigase 7.0.0

Tue, 02/24/2015 - 07:13

I saw related issue #2781 and I try to add: --sasl-strict=true to init.properties but nothing changes...

Categories: Tigase Forums

Tigase server administration: RE: It's not possible to login with some xmpp clients - Tigase 7.0.0

Tue, 02/24/2015 - 06:59

Ok, but with Tigase 5.2.3 we could connect without problems; there is something new on Tigase 7.0.0 regarding this aspect of implementation?

Categories: Tigase Forums

Tigase server administration: RE: It's not possible to login with some xmpp clients - Tigase 7.0.0

Tue, 02/24/2015 - 06:34

Related issue: #2781.

Unfortunately Smack (the library used by Jitsi and Spark) doesn't follow specification when it comes to SASL PLAIN and our strict implementation resulted in the experienced error.

Categories: Tigase Forums

Tigase server administration: RE: It's not possible to login with some xmpp clients - Tigase 7.0.0

Tue, 02/24/2015 - 06:31

If it could be useful the error is: "XMPPException: SASL authentication PLAIN failed: text".

Categories: Tigase Forums

Tigase server administration: It's not possible to login with some xmpp clients - Tigase 7.0.0

Tue, 02/24/2015 - 05:22

Hi,
I'm not able to login with clients like Jitsi or Spark, instead using Psi or Smack library API login succeed; Tigase version is 7.0.0.
Could be a problem regarding TLS or certificates?

Can you help me? Thanks in advance

Categories: Tigase Forums

Pages

Get in touch

We provide software products, consulting and custom development services

Tigase, Inc.
100 Pine Street, Suite 1250
San Francisco, CA 94111, USA
Phone: (415) 315 9771

Follow us on:

Twitter

Back to Top