Hello all. I'm playing with the soap toolkit from SqueakMap, but something seems to be wrong: If I run some SUnit tests (specifically client ones - such as SoapHttpClientTestCase, or SoapCallTestCase) they are failing, saying they cannot connect to the server (localhost, port 8823). However, if I step through the tests via debugging, right into the point where the call is made to the server, the call appears to work fine (a connection is made, the expected return is received).
What could be wrong here? It's almost like with the automated tests the server is dying before the tests are ever connecting.
Cheers, S
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Hi,
Do you use Squeak 3.9a? If so, I think it is partly because of the new TestRunner, which seems to be running multi-threaded now.
I will upgrade my test cases for the next release.
Cheers,
2006/1/31, Simon Kirk Simon.Kirk@pinesoft.co.uk:
Hello all. I'm playing with the soap toolkit from SqueakMap, but something seems to be wrong: If I run some SUnit tests (specifically client ones - such as SoapHttpClientTestCase, or SoapCallTestCase) they are failing, saying they cannot connect to the server (localhost, port 8823). However, if I step through the tests via debugging, right into the point where the call is made to the server, the call appears to work fine (a connection is made, the expected return is received).
What could be wrong here? It's almost like with the automated tests the server is dying before the tests are ever connecting.
Cheers, S
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
-- [:masashi | ^umezawa]
Do you use Squeak 3.9a? If so, I think it is partly because of the new TestRunner, which seems to be running multi-threaded now.
No, the old one ran multi-threaded, the new one does not. In the new test-runner the tests all run in the morphic-process and block the whole system while they are running, however they run *much* faster ...
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Hi,
Oops, my guess was completely wrong. I should have looked at the actual code.
2006/2/1, Lukas Renggli renggli@gmail.com:
Do you use Squeak 3.9a? If so, I think it is partly because of the new TestRunner, which seems to be running multi-threaded now.
No, the old one ran multi-threaded, the new one does not. In the new test-runner the tests all run in the morphic-process and block the whole system while they are running, however they run *much* faster ...
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
-- [:masashi | ^umezawa]
Hi Masashi.
No, this is on Squeak 3.8 (Smalltalk vmVersion returns 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548]'), SUnit version 3.1.22, SoapCore 0.8.
It certainly seems like some kind of threading/timing issue - but things are very strange. For a bit more detail: If I put a break point in the method "testSimpleEnvelopeSend" in SoapHttpClientTestCase thus:
testSimpleEnvelopeSend
| curPort retXML envelope body method | SoapServerSetup startOnly: #(http). SoapServiceHandler default add: self simpleService. curPort := SoapSetting defaultPortAt: #http. self halt. ' <--------- Here's the break point retXML := (SoapHttpClient url: 'http://localhost:', curPort printString, '/' ) send: self simpleEnvelope. envelope := SoapEnvelopeBuilder new buildSoapEnvelopeFromXmlString: retXML. [snip]
Then if I wait a few seconds, the proceed, that test send works. If I press process quickly, then it doesn't work.
So it looks like the section where the simpleService is added to the server isn't being given enough time to establish a listening port. Does that look correct?
Cheers, Simon
Masashi UMEZAWA wrote:
Hi,
Do you use Squeak 3.9a? If so, I think it is partly because of the new TestRunner, which seems to be running multi-threaded now.
I will upgrade my test cases for the next release.
Cheers,
2006/1/31, Simon Kirk Simon.Kirk@pinesoft.co.uk:
Hello all. I'm playing with the soap toolkit from SqueakMap, but something seems to be wrong: If I run some SUnit tests (specifically client ones - such as SoapHttpClientTestCase, or SoapCallTestCase) they are failing, saying they cannot connect to the server (localhost, port 8823). However, if I step through the tests via debugging, right into the point where the call is made to the server, the call appears to work fine (a connection is made, the expected return is received).
What could be wrong here? It's almost like with the automated tests the server is dying before the tests are ever connecting.
Cheers, S
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
-- [:masashi | ^umezawa]
Hi,
I've tested SoapCore 0.8 on Windows VM (Squeak-Win32-3.7.1-VM.zip) and the image is Squeak 3.8-6665.
SoapHttpClientTestCase >> #testSimpleEnvelopeSend runs perfectly well.
So, maybe it's a VM issue. I'll test the same test case in Linux VM. So, just wait for a moment.
2006/2/1, Simon Kirk Simon.Kirk@pinesoft.co.uk:
Hi Masashi.
No, this is on Squeak 3.8 (Smalltalk vmVersion returns 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548]'), SUnit version 3.1.22, SoapCore 0.8.
It certainly seems like some kind of threading/timing issue - but things are very strange. For a bit more detail: If I put a break point in the method "testSimpleEnvelopeSend" in SoapHttpClientTestCase thus:
testSimpleEnvelopeSend
| curPort retXML envelope body method | SoapServerSetup startOnly: #(http). SoapServiceHandler default add: self simpleService. curPort := SoapSetting defaultPortAt: #http. self halt. ' <--------- Here's the break point retXML := (SoapHttpClient url: 'http://localhost:', curPort
printString, '/' ) send: self simpleEnvelope. envelope := SoapEnvelopeBuilder new buildSoapEnvelopeFromXmlString: retXML. [snip]
Then if I wait a few seconds, the proceed, that test send works. If I press process quickly, then it doesn't work.
So it looks like the section where the simpleService is added to the server isn't being given enough time to establish a listening port. Does that look correct?
Cheers, Simon
Masashi UMEZAWA wrote: Hi,
Do you use Squeak 3.9a? If so, I think it is partly because of the new TestRunner, which seems to be running multi-threaded now.
I will upgrade my test cases for the next release.
Cheers,
2006/1/31, Simon Kirk Simon.Kirk@pinesoft.co.uk:
Hello all. I'm playing with the soap toolkit from SqueakMap, but something seems to be wrong: If I run some SUnit tests (specifically client ones - such as SoapHttpClientTestCase, or SoapCallTestCase) they are failing, saying they cannot connect to the server (localhost, port 8823). However, if I step through the tests via debugging, right into the point where the call is made to the server, the call appears to work fine (a connection is made, the expected return is received).
What could be wrong here? It's almost like with the automated tests the server is dying before the tests are ever connecting.
Cheers, S
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
-- [:masashi | ^umezawa]
-- [:masashi | ^umezawa]
Further investigations seem to indicate that the SOAP server is refusing the first connection attempt in any given startup. If this expected? Since there are quite a few stop/starts happening as part of the unit test suite, and since things like the methods in SoapHttpClientTestCase only do one send per stop/start cycle, they are coming back as false.
Anyway, I've worked around around it for now by editing the class method "start" in SoapServerSetup, so that after the handler is started a temporary socket is created, connected to the handler's port (or not, as the case may be :), then disconnected. After that all the unit tests for the soap package that I was basing my code on pass! :)
Sorry I can't help out more... S
Simon Kirk wrote:
Hi Masashi.
No, this is on Squeak 3.8 (Smalltalk vmVersion returns 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548]'), SUnit version 3.1.22, SoapCore 0.8.
It certainly seems like some kind of threading/timing issue - but things are very strange. For a bit more detail: If I put a break point in the method "testSimpleEnvelopeSend" in SoapHttpClientTestCase thus:
testSimpleEnvelopeSend
| curPort retXML envelope body method | SoapServerSetup startOnly: #(http). SoapServiceHandler default add: self simpleService. curPort := SoapSetting defaultPortAt: #http. self halt. ' <--------- Here's the break point retXML := (SoapHttpClient url: 'http://localhost:', curPort
printString, '/' ) send: self simpleEnvelope. envelope := SoapEnvelopeBuilder new buildSoapEnvelopeFromXmlString: retXML. [snip]
Then if I wait a few seconds, the proceed, that test send works. If I press process quickly, then it doesn't work.
So it looks like the section where the simpleService is added to the server isn't being given enough time to establish a listening port. Does that look correct?
Cheers, Simon
Masashi UMEZAWA wrote:
Hi,
Do you use Squeak 3.9a? If so, I think it is partly because of the new TestRunner, which seems to be running multi-threaded now.
I will upgrade my test cases for the next release.
Cheers,
2006/1/31, Simon Kirk Simon.Kirk@pinesoft.co.uk:
Hello all. I'm playing with the soap toolkit from SqueakMap, but something seems to be wrong: If I run some SUnit tests (specifically client ones - such as SoapHttpClientTestCase, or SoapCallTestCase) they are failing, saying they cannot connect to the server (localhost, port 8823). However, if I step through the tests via debugging, right into the point where the call is made to the server, the call appears to work fine (a connection is made, the expected return is received).
What could be wrong here? It's almost like with the automated tests the server is dying before the tests are ever connecting.
Cheers, S
This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
-- [:masashi | ^umezawa]
Click here https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== to report this email as spam.
squeak-dev@lists.squeakfoundation.org