On 19.07.2006 21:23 CE(S)T, Lars T. Mikkelsen wrote:
> Did you check if there are any hints in the
> logfile of the Jabber server?

Wildfire's error.log says this each time a transport is trying to connect:

2006.07.19 22:40:41
[org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:161)]
Verbindung beendet bevor Sitzung hergestellt wurde
Socket[addr=/127.0.0.1,port=42350,localport=5347]

In English it means: Connection closed before session was established.

The other logs contain no entries.

-- 
Yves Goergen "LonelyPixel" <[EMAIL PROTECTED]>
http://beta.unclassified.de ? My web laboratory.
From [EMAIL PROTECTED]  Wed Jul 19 20:56:27 2006
From: [EMAIL PROTECTED] (David E Freitas)
Date: Wed Jul 19 20:56:31 2006
Subject: [py-transports] Re: PyMSNt losing messages with ejabberd
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

> It does seem to be a little better now.

Better after increasing the shaper's limit?

This lost messages is a real problem.

Most of our users lose messages, mostly messages coming IN to them on
the gateway.

Specially when above 1500 concurrent.
I don't trust typing notifications for some reason.

Twisted 1.3
PyMSNt 0.11.1
Python 2.4
ejabberd 0.9.8


Sincerely,


David


P.S. Is Twisted 2.4 not supported by PyMSNt yet?


On 7/12/06, James Bunton <[EMAIL PROTECTED]> wrote:
> On 12/07/2006, at 3:18 PM, Trejkaz wrote:
>
> >
> >> I'm kind of at a loss as to what's going on here. I would really
> >> appreciate anybody's insight.
> >
> > FWIW, I've tried bumping up the shaper's limit, just to see if that
> > really
> > was the issue.  I won't really know until the load hits the point
> > again.
> >
> > TX
>
> It does seem to be a little better now.
>
> Btw, I found the source of the duplicate debug log entries. Silly
> error in debug.py that is only triggered if you send the transport a
> SIGHUP.
>
> Its fixed in svn trunk.
>
> ---
>
> James
>
> _______________________________________________
> py-transports mailing list
> [email protected]
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
From [EMAIL PROTECTED]  Wed Jul 19 21:03:27 2006
From: [EMAIL PROTECTED] (Yves Goergen)
Date: Wed Jul 19 21:03:22 2006
Subject: [py-transports] Cannot start PyMSNt and PyICQt
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On 17.07.2006 17:13 CE(S)T, Yves Goergen wrote:
> I just updated to Linux kernel 2.6.17.6 and now PyMSNt and PyICQt don't work
> anymore. The applications are running but both show this in their debug
> output
> all the time:

I was just told that my JRU-PHP installation doesn't work anymore.
Here's what the web server's error log says about the error 500:

PHP Warning:  stream_socket_enable_crypto(): SSL operation failed with
code 108. OpenSSL Error messages:, referer:
http://beta.unclassified.de/projekte/jru-php/jru.php
error:00000000:lib(0):func(0):reason(0) in
/.../projekte/jru-php/class.jabber.php on line 1154, referer:
http://beta.unclassified.de/projekte/jru-php/jru.php

(only the relevant parts)

So OpenSSL makes trouble. It did that before, but not in this situation.
Maybe this has also something to do with the new kernel? I think I'm
reverting to an older one tomorrow. It'll be insecure as hell but right
now it doesn't work at all. :(

-- 
Yves Goergen "LonelyPixel" <[EMAIL PROTECTED]>
http://beta.unclassified.de ? My web laboratory.
From [EMAIL PROTECTED]  Wed Jul 19 22:59:07 2006
From: [EMAIL PROTECTED] (Lars T. Mikkelsen)
Date: Wed Jul 19 22:59:26 2006
Subject: [py-transports] Cannot start PyMSNt and PyICQt
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

On Wed, Jul 19, 2006 at 11:03:27PM +0200, Yves Goergen wrote:
> PHP Warning:  stream_socket_enable_crypto(): SSL operation failed with
> code 108. OpenSSL Error messages:, referer:
> http://beta.unclassified.de/projekte/jru-php/jru.php
> error:00000000:lib(0):func(0):reason(0) in
> /.../projekte/jru-php/class.jabber.php on line 1154, referer:
> http://beta.unclassified.de/projekte/jru-php/jru.php
> 
> (only the relevant parts)
> 
> So OpenSSL makes trouble. It did that before, but not in this situation.
> Maybe this has also something to do with the new kernel? I think I'm
> reverting to an older one tomorrow. It'll be insecure as hell but right
> now it doesn't work at all. :(

I think the OpenSSL issue is related to the issues with the
Py-transports. I suspect the error code 108 is returned because the
connection was closed prematurely - this also seems to be the problem
with the transports. I have no idea why the connection is closed,
however, I think you could try a couple of things:

* Manually connect to the Jabber server (e.g. echo "<stream:stream>" |
  nc -vvv localhost 5347) and see if you get a response.
* Check if the loopback devices is properly configured (ifconfig lo).
* Check if the issue is still present with the latest kernel prepatch
  (currently 2.6.18-rc2).

Best regards,
Lars
From [EMAIL PROTECTED]  Thu Jul 20 00:02:02 2006
From: [EMAIL PROTECTED] (Matthew Anderson)
Date: Thu Jul 20 00:02:08 2006
Subject: [py-transports] pyAIMt bugs, take two
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Daniel (and whomever else might know) --

So, what happens if pyAIMt gets a service discovery response that has  
no 'feature' elements in it?

It might be that the problem is this:  pyAIMt gets a presence packet  
which indirectly causes the problem to manifest itself *because* the  
registration process continues as it should.  The Psi jabber client  
has a service discovery response of:

   <iq xmlns='jabber:client' type='result' to='aim.bebop' id='4'  
from='[EMAIL PROTECTED]/Psi'>
   <query xmlns='http://jabber.org/protocol/disco#info'>
   <feature var='http://jabber.org/protocol/bytestreams'/>
   <feature var='http://jabber.org/protocol/si'/>
   <feature var='http://jabber.org/protocol/si/profile/file-transfer'/>
   </query>
   </iq>

Where my component's service discovery response is:

   <iq xmlns='jabber:client' type='get' to='aim.bebop' from='bebop'  
id='iv8c1us1'><query
   xmlns='http://jabber.org/protocol/disco#info'/></iq>

This would be consistent with the message from the traceback:

   self.pytrans.discovery.sendIq(iq).addCallback(self.gotCapabilities)
   exceptions.AttributeError: 'NoneType' object has no attribute  
'discovery'
   wrapped xmlstream functions

And, the next stanza in the input after the traceback (I would have  
expected it to come before, but...) is the service discovery response  
above.

Weird how things can not make sense for a long time, and then  
something clicks and you say "aha!  maybe that's it.".

Anyway, my guess is that's it.  Things break if a service discovery  
response has no features.

I don't know that I have any features I want to broadcast.  If that's  
the problem though, I guess I have to come up with something.

On Jul 19, 2006, at 2:58 PM, Daniel Henninger wrote:

>
> On Jul 19, 2006, at 1:39 PM, Matthew Anderson wrote:
>
>> Hi --
>>
>> I never received any comment of any kind on my last query /  
>> message to the list, and I still have yet to figure out exactly  
>> how to get my component to talk to the pyAIMt component.
>
> I don't recall seeing another message.  Maybe it got lost in spam.  =/
>
>>
>> However, I have zeroed in exactly on one of the things that is  
>> causing a traceback in pyAIMt.  If it receives an unexpected  
>> presence stanza (without a type, indicating available) it suffers  
>> a meltdown.  If I send a <presence type=probe /> stanza instead,  
>> it simply reports <presence type="unavailable" /> with no  
>> traceback.  I assume this issue would be the same for the other  
>> gateways with the same foundation code, though I've only attempted  
>> to work with pyAIMt.
>
> Define meltdown.  =)  If it weren't capable of testing with a type- 
> less presence, it wouldn't have gotten very far!  =)  (ie, it  
> certainly works with my tests)
>
>> Also, several times now after getting pyAIMt sufficiently confused  
>> (2-3 tracebacks w/o actually shutting it down), pyAIMt has ceased  
>> to function entirely, to the point that even a proper jabber  
>> client can no longer interact with it successfully.  Deleting the  
>> pyAIMt spool files has no effect, restarting the jabberd2 server  
>> has no effect, rebooting the server has no effect -- in fact, the  
>> only way I've gotten it working again at all is to do a drop of  
>> the jabberd2 mysql database, run the init script again, and re- 
>> register the test users.
>
> what the...  that's very bizarre!
>
>> Does anybody have any insight as to why these unexpected presence  
>> fragments would be such a big problem?
>
> Aside from "that shouldn't happen"?  ;)  Does running it with the - 
> D option help identify what's going on any?  (it being PyAIMt)
>
>> Does anybody have any idea what could be tweaked in system state  
>> where pyAIMt would be broken, and then fixed by dropping the  
>> jabberd2 database and making a new one?
>
> Well, like I said, I test it with jabberd2 amongst other servers  
> and I've never run into such problems.  Color me confused.
>
>> If it's helpful, a diff of the mysqldumps before and after the  
>> database refresh (and after the single user has re-registered) are  
>> below.
>>
>> Thanks,
>> --
>>  Matt Anderson
>>
>>
>>
>> dominar: [~/Desktop] % diff jabberd-broken.mysql after-resetup.mysql
>> 38c38
>> < INSERT INTO `active` VALUES ('[EMAIL PROTECTED]',1,1152483537);
>> ---
>> > INSERT INTO `active` VALUES ('[EMAIL PROTECTED]',1,1153325786);
>> 65c65
>> < INSERT INTO `authreg` VALUES  
>> ('matt','bebop','CENSORED','44B180D1', 
>> 500,'9ab1d87180cd57442f7cfafa7476b4bc38d346c8');
>> ---
>> > INSERT INTO `authreg` VALUES  
>> ('matt','bebop','CENSORED','44BE5ADA', 
>> 500,'5088ade3aaeb32e3ffbaa7aa072ccf3a4ec8e3a4');
>> 114d113
>> < INSERT INTO `logout` VALUES ('[EMAIL PROTECTED]',2,1152563700);
>> 310d308
>> < INSERT INTO `roster-items` VALUES ('[EMAIL PROTECTED]', 
>> 23,'aim.bebop',NULL,0,1,0),('[EMAIL PROTECTED]', 
>> 9,'[EMAIL PROTECTED]',NULL,1,1,0),('[EMAIL PROTECTED]', 
>> 16,'[EMAIL PROTECTED]',NULL,1,1,0);
>> 377d374
>> < INSERT INTO `vcard` VALUES ('[EMAIL PROTECTED]', 
>> 1,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NU 
>> LL,NULL,NULL,NULL,NULL,NULL);
>>
>> _______________________________________________
>> py-transports mailing list
>> [email protected]
>> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
> _______________________________________________
> py-transports mailing list
> [email protected]
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports

--
  Matt Anderson

Reply via email to