sip_ve_1_0 not working anymore

[ced...@telcoinabox.com]

Hi Seb,

Just going back on track with testerman. Did you change anything modifying ptc behaviour ?

I just made a fresh install of testerman and tried to use your sample but it seems that the sip message are not really sent and that the ptc of the endpoint never clear.

I have to kill the test to stop it.

Any ideas on a change which might imply this behaviour ?

Thanks for your help.

Regards,

Cedric

[ced...@telcoinabox.com]

It seems that I got the same issue when running watcherfile.ats - ATS is not ending properly.

Also, each time I launch one test with qtesterman, I got 2 instances of the same tests been launch at the same time...

20140502 16:07:10.890 INFO     root     Updating from server: hot log from job 54...

20140502 16:07:10.901 INFO     root     Loading log...

20140502 16:07:10.973 INFO     root     Parsing logs...

20140502 16:07:10.974 INFO     root     Logs parsed, DOM constructed

20140502 16:07:11.007 INFO     root     Clearing views...

20140502 16:07:11.026 INFO     root     Analyzing events...

20140502 16:07:11.065 INFO     root     Preparing views...

20140502 16:07:11.075 INFO     root     View displayed

20140502 16:07:11.076 INFO     root     Loading duration: 0.173999786377

Traceback (most recent call last):

  File "C:\Users\clegoux\Documents\testerman\LogViewer.py", line 935, in killJob

    getProxy().sendSignal(self.jobId, "kill")

  File "C:\Users\clegoux\Documents\testerman\TestermanClient.py", line 498, in s

endSignal

    res = self.__proxy.sendSignal(jobId, signal)

  File "C:\Users\clegoux\Documents\testerman\TestermanClient.py", line 53, in __

call__

    raise e

xmlrpclib.Fault: <Fault 1: "<type 'exceptions.TypeError'>:%d format: a number is

 required, not NoneType">

20140502 16:07:55.226 INFO     root     LogViewer window closed.

20140502 16:10:04.963 INFO     root     LogViewer window closed.

20140502 16:10:08.654 INFO     root     Selected groups for this run:

20140502 16:10:08.851 INFO     root     Updating logs from source...

20140502 16:10:08.852 INFO     root     Updating from server: hot log from job 56...

20140502 16:10:08.871 INFO     root     Loading log...

20140502 16:10:08.938 INFO     root     Parsing logs...

20140502 16:10:08.940 INFO     root     Logs parsed, DOM constructed

20140502 16:10:08.971 INFO     root     Clearing views...

20140502 16:10:08.993 INFO     root     Analyzing events...

20140502 16:10:09.029 INFO     root     Preparing views...

20140502 16:10:09.039 INFO     root     View displayed

20140502 16:10:09.039 INFO     root     Loading duration: 0.167999982834

20140502 16:11:25.857 INFO     root     LogViewer window closed.

20140502 16:12:20.055 INFO     root     Selected groups for this run:

20140502 16:12:20.262 INFO     root     Updating logs from source...

20140502 16:12:20.263 INFO     root     Updating from server: hot log from job 58...

20140502 16:12:20.276 INFO     root     Loading log...

20140502 16:12:20.346 INFO     root     Parsing logs...

20140502 16:12:20.348 INFO     root     Logs parsed, DOM constructed

20140502 16:12:20.381 INFO     root     Clearing views...

20140502 16:12:20.401 INFO     root     Analyzing events...

20140502 16:12:20.440 INFO     root     Preparing views...

20140502 16:12:20.451 INFO     root     View displayed

20140502 16:12:20.453 INFO     root     Loading duration: 0.176000118256

Probably doing something wrong somewhere. Using qtesterman 1.5.1 and latest version of server.

Thanks !!!

Cedric

[Sébastien Lefèvre]

Hi Cédric,

Looks like an issue I've met a couple of times without being able to pinpoint or reproduce it in a controlled env, I'll check this more closely.

I'll look at the double ats run too. This one is new to me though.

Thanks,
-seb

--
You received this message because you are subscribed to the Google Groups "Testerman Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to testerman-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sébastien Lefèvre]

Hi Cédric,

1. FileWatcherProbe: the "problem" was in the probe itself, though I don't understand it. glob.glob() when called from a subthread seems to hangs when importing os or posixpath. I don't remember having this behavior when writing the probe several years ago, don't know if it's a regression in Python 2.7 standard libs or something I used incorrectly. Still to investigate but the probe now works (commit e91dd1d).

2. Do you have a way to reproduce your SIP VE PTC problem ? an ATS or package maybe ? would be great !

3. Double ATS run from qtesterman: which python/pyqt version ? which platform ? (win32/64/linux distrib... ?)

How to run the ATS ? (group/custom profile/standard/other... ?)

thanks,

-seb

--
Sebastien Lefevre
seb.l...@gmail.com

[Cedric Legoux]

Thanks Seb,

For the SIP VE PTC problem, I am just using the sample ats as present in GIT.

even if in the log the probe "seems" sending the SIP packet if I make a tcpdum I can't see anything and the probe does not seems to receive it neither. 

I will have a deeper look today again. I am suspecting a similar problem as FileWatcher probe as it was working before...maybe something with Python 2.7 that I am also using today.

To reproduce in my case:

sample.ats

TC_SIPVE_API_VE2VE

run standard/default profile.

I will let you know If I find something.

Thanks again.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

   

telcoinabox.com.au

--
You received this message because you are subscribed to a topic in the Google Groups "Testerman Users Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/testerman-users/4Yb2LsvZ19Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to testerman-use...@googlegroups.com.

[Cedric Legoux]

Hi Seb,

From my tests it seems that socket.sendto() hangs in the context of the virtual endpoint.

I still can't explain it though. I tried to reproduce with a simple ptc but without success.

I still haven't found which difference leads to this issue.

I will keep looking on my free time.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

   

telcoinabox.com.au

[Cedric Legoux]

Hi Seb,

I found the issue with the virtual endpoint. Somewhere down the road the ATS parameters are encoded in unicode and this value was given in unicode to the probe. It seems that the sendto method does not like unicode encoded ip address.

I am now looking at the dual ATS issue. It seems that the xml message is send twice. One with the previous TCP connection and one with a new TCP connection. Server only answers on the new one but it seems that he handles both request of scheduling the ATS... I am still trying to understand why.

I will let you know.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

   

telcoinabox.com.au

[Cedric Legoux]

Hi seb,

Found the issue for my double ATS. I am running python 2.6.6 on my server and it seems that it does not like FixedSimpleXMLRPCServer...not sure which version should use this file though.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

   

telcoinabox.com.au

[Sébastien Lefèvre]

Hi Cédric,

Gald you found a workaround to the VE problem. However this looks like the same kind of problem as for the filewatcher probe not stopping correctly, because being stuck in glob.glob(): in both case we hang in a import in a thread. So we can expect other problems like this one.

What's interesting is that it is possible to run the TE directly from the command like, from an unzipped TE egg, with:

python ./main.py : the wrapper that import ats, repository deps and run ats/main_te.py : won't work (hangs in import)

cd ats ; export PYTHONPATH=repository/... ; python main_te.py : will work correctly ! (no problem when importing modules, in the VE case an import when looking to decode the unicode address as a possible "idna" (international domain name)).

There is something I don't understand about these imports for sure (yet it used to work with at least an unidentified python version).

[Sébastien Lefèvre]

The testerman client is supposed to maintain a XMLRPC (HTTP) connection alive to the server for performance reason - this really improves things when running the Ws interface on a slow link (server on one site, client on another one).

This is supposed to work flawlessly (of course :-) when both the client and server are running a Python 2.7 version, from which the XMLRPC default server/client implementation supports HTTP 1.1 keep-alive.

Mixing a 2.7 client with a 2.6 server is indeed untested, though the client should detect that HTTP/1.1 KA is not supported by the server.

FixedSimpleXMLRPCServer may be useless starting with a certain version of Python 2.6, not sure I've tested with 2.6.6 at the time. Can you test with the standard SimpleXMLRPCServer (TestermanServer.py:43 : make the condition always false so that we always use the python distrib's SimpleXMLRPCServer module) ?

thanks,

-seb

[Cedric Legoux]

Thanks Sébastien,

I finally found the same last Friday. Problems arrived with the introduction of 1.4.2 version of testerman. I read somewhere that import was blocking until it gets the result in the case of thread doing imports you can arrive in dead locks. That make sense to explain why it was working before as the egg is adding an import level. 

I rolled back to an older version of testerman And don't have anymore problems of dead lock. 

I don't know how to fix the issue to use the egg though. 

Regards,

Cédric

Sent from my iPhone

On 10 mai 2014, at 20:59, Sébastien Lefèvre <seb.l...@gmail.com> wrote:

Hi Cédric,

Gald you found a workaround to the VE problem. However this looks like the same kind of problem as for the filewatcher probe not stopping correctly, because being stuck in glob.glob(): in both case we hang in a import in a thread. So we can expect other problems like this one.

What's interesting is that it is possible to run the TE directly from the command like, from an unzipped TE egg, with:

python ./main.py : the wrapper that import ats, repository deps and run ats/main_te.py : won't work (hangs in import)

cd ats ; export PYTHONPATH=repository/... ; python main_te.py : will work correctly ! (no problem when importing modules, in the VE case an import when looking to decode the unicode address as a possible "idna" (international domain name)).

There is something I don't understand about these imports for sure (yet it used to work with at least an unidentified python version).

2014-05-08 6:46 GMT+02:00 Cedric Legoux <ced...@telcoinabox.com>:

Hi Seb,

I found the issue with the virtual endpoint. Somewhere down the road the ATS parameters are encoded in unicode and this value was given in unicode to the probe. It seems that the sendto method does not like unicode encoded ip address.

I am now looking at the dual ATS issue. It seems that the xml message is send twice. One with the previous TCP connection and one with a new TCP connection. Server only answers on the new one but it seems that he handles both request of scheduling the ATS... I am still trying to understand why.

I will let you know.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

On 5 May 2014 14:22, Cedric Legoux <ced...@telcoinabox.com> wrote:

Hi Seb,

From my tests it seems that socket.sendto() hangs in the context of the virtual endpoint.

I still can't explain it though. I tried to reproduce with a simple ptc but without success.

I still haven't found which difference leads to this issue.

I will keep looking on my free time.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

On 5 May 2014 09:00, Cedric Legoux <ced...@telcoinabox.com> wrote:

Thanks Seb,

For the SIP VE PTC problem, I am just using the sample ats as present in GIT.

even if in the log the probe "seems" sending the SIP packet if I make a tcpdum I can't see anything and the probe does not seems to receive it neither. 

I will have a deeper look today again. I am suspecting a similar problem as FileWatcher probe as it was working before...maybe something with Python 2.7 that I am also using today.

To reproduce in my case:

sample.ats

TC_SIPVE_API_VE2VE

run standard/default profile.

I will let you know If I find something.

Thanks again.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

--
Sebastien Lefevre
seb.l...@gmail.com

[Cedric Legoux]

Thanks. 

I will try And upgrade the server to python 2.7 And Check the behaviour. 

Have a good week end. 

Regards,

Cédric 

Sent from my iPhone

On 10 mai 2014, at 21:06, Sébastien Lefèvre <seb.l...@gmail.com> wrote:

The testerman client is supposed to maintain a XMLRPC (HTTP) connection alive to the server for performance reason - this really improves things when running the Ws interface on a slow link (server on one site, client on another one).

This is supposed to work flawlessly (of course :-) when both the client and server are running a Python 2.7 version, from which the XMLRPC default server/client implementation supports HTTP 1.1 keep-alive.

Mixing a 2.7 client with a 2.6 server is indeed untested, though the client should detect that HTTP/1.1 KA is not supported by the server.

FixedSimpleXMLRPCServer may be useless starting with a certain version of Python 2.6, not sure I've tested with 2.6.6 at the time. Can you test with the standard SimpleXMLRPCServer (TestermanServer.py:43 : make the condition always false so that we always use the python distrib's SimpleXMLRPCServer module) ?

thanks,

-seb

2014-05-08 7:29 GMT+02:00 Cedric Legoux <ced...@telcoinabox.com>:

Hi seb,

Found the issue for my double ATS. I am running python 2.6.6 on my server and it seems that it does not like FixedSimpleXMLRPCServer...not sure which version should use this file though.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

On 8 May 2014 14:46, Cedric Legoux <ced...@telcoinabox.com> wrote:

Hi Seb,

I found the issue with the virtual endpoint. Somewhere down the road the ATS parameters are encoded in unicode and this value was given in unicode to the probe. It seems that the sendto method does not like unicode encoded ip address.

I am now looking at the dual ATS issue. It seems that the xml message is send twice. One with the previous TCP connection and one with a new TCP connection. Server only answers on the new one but it seems that he handles both request of scheduling the ATS... I am still trying to understand why.

I will let you know.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

On 5 May 2014 14:22, Cedric Legoux <ced...@telcoinabox.com> wrote:

Hi Seb,

From my tests it seems that socket.sendto() hangs in the context of the virtual endpoint.

I still can't explain it though. I tried to reproduce with a simple ptc but without success.

I still haven't found which difference leads to this issue.

I will keep looking on my free time.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

On 5 May 2014 09:00, Cedric Legoux <ced...@telcoinabox.com> wrote:

Thanks Seb,

For the SIP VE PTC problem, I am just using the sample ats as present in GIT.

even if in the log the probe "seems" sending the SIP packet if I make a tcpdum I can't see anything and the probe does not seems to receive it neither. 

I will have a deeper look today again. I am suspecting a similar problem as FileWatcher probe as it was working before...maybe something with Python 2.7 that I am also using today.

To reproduce in my case:

sample.ats

TC_SIPVE_API_VE2VE

run standard/default profile.

I will let you know If I find something.

Thanks again.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

<image001.jpg> 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

<image002.jpg> <image003.jpg> <image004.jpg> <image005.jpg>

telcoinabox.com.au

--
Sebastien Lefevre
seb.l...@gmail.com

[Cedric Legoux]

Hi Sebastien,

I upgraded my server to Python2.7 and revert the change on the xmlrpclib of my client and this is working well again.

Thanks for the tip.

Regards,

Cedric

Cedric Legoux| Senior VOIP System Engineer |

 

 

Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

   

telcoinabox.com.au

[Sébastien Lefèvre]

Hi Cédric,

I've committed a fix that change the way the TE is built so that we avoid this import locking problem (clearly executing all the code in a single import is dirty and a bad idea :-).

If you can give it a shot and see if it works as you would expect, it would be great.

thanks,

-seb

[Cedric Legoux]

Thanks Seb,

Installed and so far I did not have any freeze with my ATS which were having problem before.

I do need to add a function in TestermanTTCN3 to modify the name of a timer as used in the virtual endpoint.

Can I commit this change ?

        def setNewName(self, name = None):

                self._name = name

I also modified Udp probes to print the beginning of the data sent instead of UDP data ... which made my log much easier to read to debug my SIP session. Let me know how does it work in term of commit right.

Thanks.

Regards,

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

T: +61 2 8248 9036

   

telcoinabox.com.au

[Cedric Legoux]

Hi Seb,

However, I went back to the behaviour where my ATS are launched twice (running python2.7 does not change the behaviour). Also doing ./bin/testerman-admin stop all does not stop the server.

I don't have any problem with version 1.2.x of the server

Regards,

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

T: +61 2 8248 9036

   

telcoinabox.com.au

[Cedric Legoux]

Hi Seb,

Just detected a small glitch on the server.

in         TestermanTTCN3.py

def cleanSystemQueueNotifier(self, force = False):

#                if (force or self._systemQueueNotifierUserCount <= 0) and self._systemQueueNotifier:

                if (force or self._systemQueueNotifierUserCount >= 0) and self._systemQueueNotifier:

Regards,

Cedric Legoux| Senior VOIP System Engineer |

 

 
Telcoinabox Operations Pty Limited | Level 10, 9 Hunter Street | Sydney, NSW 2000

T: +61 2 8248 9036

    

telcoinabox.com.au

[Sébastien Lefèvre]

Hi Cedric,

let's close this thread and not use it for all bug reports.

I'll contact you.

thanks,

-seb