Age | Commit message (Collapse) | Author |
|
|
|
Calling reconnect() simultaneously from multiple threads (like when
using XEP-0199 keepalive) could break because the connection state
can transition and break the state expectations in one of the
reconnect() calls.
|
|
This may need to be reverted if CTRL-C handling breaks, but everything
works fine so far in testing.
Resolves issue #95.
|
|
|
|
|
|
|
|
|
|
Conflicts:
examples/ping.py
sleekxmpp/basexmpp.py
sleekxmpp/clientxmpp.py
sleekxmpp/features/feature_bind/bind.py
sleekxmpp/features/feature_mechanisms/mechanisms.py
sleekxmpp/plugins/gmail_notify.py
sleekxmpp/plugins/jobs.py
sleekxmpp/plugins/xep_0009/remote.py
sleekxmpp/plugins/xep_0009/rpc.py
sleekxmpp/plugins/xep_0012.py
sleekxmpp/plugins/xep_0045.py
sleekxmpp/plugins/xep_0050/adhoc.py
sleekxmpp/plugins/xep_0078/legacyauth.py
sleekxmpp/plugins/xep_0085/chat_states.py
sleekxmpp/plugins/xep_0199/ping.py
sleekxmpp/plugins/xep_0224/attention.py
sleekxmpp/xmlstream/handler/waiter.py
sleekxmpp/xmlstream/matcher/xmlmask.py
sleekxmpp/xmlstream/xmlstream.py
Conflicts:
examples/ping.py
sleekxmpp/basexmpp.py
sleekxmpp/clientxmpp.py
sleekxmpp/features/feature_bind/bind.py
sleekxmpp/features/feature_mechanisms/mechanisms.py
sleekxmpp/plugins/gmail_notify.py
sleekxmpp/plugins/jobs.py
sleekxmpp/plugins/xep_0009/remote.py
sleekxmpp/plugins/xep_0009/rpc.py
sleekxmpp/plugins/xep_0012.py
sleekxmpp/plugins/xep_0045.py
sleekxmpp/plugins/xep_0050/adhoc.py
sleekxmpp/plugins/xep_0078/legacyauth.py
sleekxmpp/plugins/xep_0085/chat_states.py
sleekxmpp/plugins/xep_0199/ping.py
sleekxmpp/plugins/xep_0224/attention.py
sleekxmpp/xmlstream/handler/waiter.py
sleekxmpp/xmlstream/matcher/xmlmask.py
sleekxmpp/xmlstream/xmlstream.py
|
|
|
|
|
|
~ 15% of CPU on moderate load.
|
|
|
|
computing logging data that may never be used. This is a HUGE performance improvement; in some of my test runs, unnecessary string creation was accounting for > 60% of all CPU time.
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
|
|
computing logging data that may never be used. This is a HUGE performance improvement; in some of my test runs, unnecessary string creation was accounting for > 60% of all CPU time.
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
|
|
auto_reconnect=False.
|
|
It messes up the auto_reconnect value and causes the XML processing
loop to spin wildly with errors on a stream disconnect.
|
|
The transition from disconnected to connected states must be done in a
loop in case the transition fails, not just once and hope it worked.
|
|
|
|
Fixes issue #103
|
|
The processing loop was continuing to call __read_xml after </stream>
was received, which caused SyntaxErrors (can't find starting element).
This should fix issue #102
|
|
|
|
May be disabled by setting:
self.whitespace_keepalive = False
The keepalive interval can be adjusted using:
self.whitespace_keepalive_interval = 300
The default interval is 5min.
|
|
|
|
Now defaults xmlstream.WAIT_TIMEOUT, and settable with
self.wait_timeout.
The new default timeout is 1sec instead of 5sec.
|
|
This can be overridden to do custom configuration for the DNS resolver,
or any other DNS related tasks such as calling the system's res_init().
|
|
e.g.
self.session_timeout = 15
It is also managed by XMLStream instead of ClientXMPP now.
|
|
|
|
|
|
Scheduled tasks must have a unique name.
|
|
Allows for setting app specific socket timeouts and other socket options.
|
|
|
|
Or through an equivalent override.
|
|
|
|
|
|
|
|
|
|
reconnect until exhausted
|
|
Added logging to say that we're waiting for the server to end the stream
from its end.
|
|
|
|
|
|
example to ClientXMPP.
|
|
|
|
If wait=True, then the disconnect call will block until
the send queue has emptied.
WARNING: Using wait=True when more stanzas are being added to the
queue than can be processed such that the queue is never empty
will cause the disconnect call to block indefinitely without actually
disconnecting.
|
|
The error bubbles through the event processing loop, breaking it and
hanging the application.
Instead, there is now a .exception(e) method on XMLStream which may
be overridden or reassigned that will receive all unhandled exceptions
(read: not XMPPError) from event and stream handlers.
|
|
If a stanza handler raised an exception, the exception was processed
and replied by the modified stanza, not a stanza with the original
content.
A copy is now made before handler processing, and if an exception occurs
it is the copy that processes the exception using the original content.
|
|
For now, session_end is the same as disconnected, but once support is
added later for stream management, the two events will become distinct.
Plugins should add handlers for session_end for cleaning any session
state.
|
|
The stanza will be sent first once the send queue is reactivated
after session start.
Stanzas sent by skipping the queue will not be cached.
|
|
Backoff was only being done for the initial connection attempt
before. Now any reconnection will start with a minimum 1 sec
delay which will approximately double between attempts.
|
|
The syntax and attribute errors raised during a disconnect/reconnect
attempt are now caught and produce nicer log messages.
|
|
Use the parameter now=True to skip the queue when
sending Iq stanzas, or using xmpp.send().
|