[8.0.2] Autorefresh of WWW-Page with Seaside ...

VA Smalltalk is a "100% VisualAge compatible" IDE that includes the original VisualAge technology and the popular VA Assist and WidgetKit add-ons.

Moderators: Eric Clayberg, wembley, tc, Diane Engles, solveig

[8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Thu Nov 11, 2010 12:39 pm

In my demo application I changed my updateRoot: method to introduce an auto reload of a page of my Seaside application. I added the following code to my "updateRoot:" method:

Code: Select all
anHtmlRoot meta
  responseHeaderName: 'refresh' ;
  content: 1 greaseString      


and guess what !? It works ! BUT only until I open another browser and start another session on that seaside application or just query the startup seaside page on that running Smalltalk server.
Then the browser with the autoload running stops updating and shows only the sourcecode of that page. That happens with all browsers.

Any idea how to implement an autoload in another way or how to fix this or is this a VA specific problem ?

PS1: Or an Apache configuration problem ? The configuration described above is a Smalltalk image behind an Apache 2.2 (under Windows 7 Home/64). When connecting the browsers directly against the VA-image the system is working much better - working very hard. Now I have a heavy load test suite. Only two browsers are enough to put VA at 100% working - retrieving around 128 JSON documents (each 3 KByte) in each refresh from a CouchDB, converting from Strings to dictionaries, building the pages and sending them to the client. Now from time to time strange things are happening: Seaside is producing empty pages, a socket has no handle any more ...
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby TriSebastian » Thu Nov 11, 2010 2:20 pm

Hi Marten,

there are several posibillities do force an update of certain Parts of your site.

Have a look at jQuery samples....

One imlementation might look like this.

renderContentOn: html
html paragraph
script: (html jQuery this load
html: [ :r | self renderTimeOn: r ];
interval: 1 seconds);
with: [ self renderTimeOn: html ]


renderTimeOn: html
html render: DateAndTime now

Taken from the samples ;-)

Another solution might be, but no more used. SeasideAsync originally implemented by Avi Bryant and used until Seaside 2.8

A nice solution for instant updates might also be Comet for Seaside. Not qet available for VAST.
I started porting it during Beta phase of VAST 8.0,... but is struggeld with the SeverAdapter... If you want my codeing just mail me.

Hope this helps
Sebastian
TriSebastian
 
Posts: 76
Joined: Sun Jul 20, 2008 9:40 pm
Location: Nanaimo, BC, Canada

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Thu Nov 11, 2010 10:19 pm

The demo is actually not running very long - mainly due to socket problems. The application mainly crashes in SstTcpTransport>>getNextIncomingConnection when it calls #findReadyConnection. Within this method (at the end) a "conn close" is executed and this statement crashes, because of "flush" against an instance of SstSocketStream and this stream instance has a problem: the value of the instance variable socket is nil !.

Debugger Stack Trace Report:
Error String: 'UndefinedObject does not understand sendAll:length:startingAt:flags:'
Resumable: false

Process
Name: HTTP Server Process for: http://:9345/ (1)
Process State: suspended
Priority: 3

Executing in: SstSocketStream>>#flush

System Configuration Dump


Copyright:

VA Smalltalk V8.0.2 ; Image: 8.0.2
VM Timestamp: 4.0,(NC) 5/3/2010 (80)
(C) Copyright Instantiations 1994, 2010. All rights reserved.
(C) Copyright International Business Machines Corp. 1994, 2006. All rights reserved.

Time: 07:20:51
Date: 12.11.2010

Platform:

Virtual machine: ES
Bytecode version: 4.0
Manager version: 4.00
'OS' subsystem: 'WIN32s'
'CLIM' subsystem: 'ES'
'CP' subsystem: 'WIN32s'
'CLDT' subsystem: 'ES'
'CFS' subsystem: 'WIN32s'
'SCI' subsystem: 'WIN'
'CW' subsystem: 'WIN32s'
'CPM' subsystem: 'ES'
'CG' subsystem: 'WIN32s'
'CPIC' subsystem: 'WIN32s'

Current user: Marten Feldtmann

Connected Library:

Pathname: 192.168.70.2 :: /usr/local/VASmalltalk/7.5/manager/mgr801-cummulated.dat
Library version: 6
Size of library: 615942208 bytes
Has consistent EOF: true
Acquire read locks: false
Single user mode: false
Server address: '192.168.70.2'

Library Access:

Host system name: None
Use release lock mode: true
Native primitives library: emntv50
Emsrv primitives library: emsrv50

Memory:

Total allocation: 183560072 bytes
Available: 20464128 bytes
Fixed Space: 35304 bytes
New Space: 1045040 bytes
Old Space: 19418476 bytes

=============<STACK TRACE BEGINS>============
[] in <optimized block>(ExceptionalEvent class)>>#initializeSystemExceptions
signal=Signal on Exception: (ExError) An error has occurred.
Signal>>#evaluate:
self=Signal on Exception: (ExError) An error has occurred.
aBlock=[] in ExceptionalEvent class>>#initializeSystemExceptions
Signal>>#evaluateDefaultHandler:
self=Signal on Exception: (ExError) An error has occurred.
aBlock=[] in ExceptionalEvent class>>#initializeSystemExceptions
ExceptionalEvent>>#applyDefaultHandler:
self=Exception: (ExError) An error has occurred.
aSignal=Signal on Exception: (ExError) An error has occurred.
exception=Exception: (ExError) An error has occurred.
ExceptionalEvent>>#signalFor:
self=Exception: (ExError) An error has occurred.
aSignalOrExceptionSelector=Signal on Exception: (ExError) An error has occurred.
handler=nil
ExceptionalEvent>>#signalWithArguments:
self=Exception: (ExError) An error has occurred.
arguments=('UndefinedObject does not understand sendAll:length:startingAt:flags:')
ExceptionalEvent>>#signalWith:
self=Exception: (ExError) An error has occurred.
arg1='UndefinedObject does not understand sendAll:length:startingAt:flags:'
UndefinedObject(Object)>>#error:
self=nil
aString='UndefinedObject does not understand sendAll:length:startingAt:flags:'
MessageNotUnderstood>>#defaultAction
self=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
[] in <optimized block>(Exception class)>>#newExceptionalEvent
signal=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
MessageNotUnderstood(Exception)>>#evaluateDefaultHandler:
self=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
aBlock=[] in Exception class>>#newExceptionalEvent
ExceptionalEvent>>#applyDefaultHandler:
self=Exception: (ExMessageNotUnderstood) An exception has occurred
aSignal=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
exception=Exception: (ExMessageNotUnderstood) An exception has occurred
ExceptionalEvent>>#signalFor:
self=Exception: (ExMessageNotUnderstood) An exception has occurred
aSignalOrExceptionSelector=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
handler=nil
MessageNotUnderstood(Exception)>>#signal
self=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
[] in SstInvocationHandler>>#defaultServerExceptionHandler
self=SstInvocationHandler(http://:9345/)
sig=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
sstTag=#SstTag:Trap Exception
MessageNotUnderstood(Exception)>>#evaluate:
self=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
aBlock=[] in SstInvocationHandler>>#defaultServerExceptionHandler
[] in BlockContextTemplate(Block)>>#when:do:exitWith:retryReturn:
self=[] in SstInvocationHandler>>#serverProcessBlock
exception=Exception: (ExError) An error has occurred.
handlerBlock=[] in SstInvocationHandler>>#defaultServerExceptionHandler
exitBlock=[] in Block>>#when:do:
knownResult=an Object
retryBlock=[] in Block>>#when:do:exitWith:retryReturn:
handler=[] in Block>>#when:do:exitWith:retryReturn:
oldHandler=nil
signal=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
[] in BlockContextTemplate(Block)>>#when:do:exitWith:retryReturn:
self=[] in SstSocketStream>>#close
exception=Exception: (ExSstNonFatalError) A non-fatal SST error has occurred.
handlerBlock=[] in SstSocketStream>>#close
exitBlock=[] in Block>>#when:do:
knownResult=an Object
retryBlock=[] in Block>>#when:do:exitWith:retryReturn:
handler=[] in Block>>#when:do:exitWith:retryReturn:
oldHandler=[] in Block>>#when:do:exitWith:retryReturn:
signal=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
ExceptionalEvent>>#signalFor:
self=Exception: (ExMessageNotUnderstood) An exception has occurred
aSignalOrExceptionSelector=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
handler=[] in Block>>#when:do:exitWith:retryReturn:
MessageNotUnderstood(Exception)>>#signal
self=Signal on Exception: (ExMessageNotUnderstood) An exception has occurred
MessageNotUnderstood class(Exception class)>>#signalWith:
self=MessageNotUnderstood
signallerTag=' ...etc...)))

UndefinedObject(Object)>>#doesNotUnderstand:
self=nil
aMessage=' ...etc...))

SstSocketStream>>#flush
self=a SstSocketStream
rc=nil
[] in SstSocketStream>>#close
self=a SstSocketStream
BlockContextTemplate(Block)>>#valueWithErrorHandler:oldHandler:onReturnDo:
self=[] in SstSocketStream>>#close
handler=[] in Block>>#when:do:exitWith:retryReturn:
oldHandler=[] in Block>>#when:do:exitWith:retryReturn:
completionBlock=[]
BlockContextTemplate(Block)>>#when:do:exitWith:retryReturn:
self=[] in SstSocketStream>>#close
exception=Exception: (ExSstNonFatalError) A non-fatal SST error has occurred.
handlerBlock=[] in SstSocketStream>>#close
exitBlock=[] in Block>>#when:do:
knownResult=an Object
retryBlock=[] in Block>>#when:do:exitWith:retryReturn:
handler=[] in Block>>#when:do:exitWith:retryReturn:
oldHandler=[] in Block>>#when:do:exitWith:retryReturn:
BlockContextTemplate(Block)>>#when:do:
self=[] in SstSocketStream>>#close
exception=Exception: (ExSstNonFatalError) A non-fatal SST error has occurred.
handlerBlock=[] in SstSocketStream>>#close
knownResult=an Object
result=nil
SstSocketStream>>#close
self=a SstSocketStream
SstHttpConnection(SstStreamedConnection)>>#basicClose
self=a SstHttpConnection
SstHttpConnection(SstConnection)>>#close
self=a SstHttpConnection
SstTcpTransport(SstSocketTransport)>>#findReadyConnection
self=SstTcpTransport(SstLocalEndpoint(http://:9345/))
socket=SciSocket <P/Handle = 3016 Type = 1 Protocol = 0>
conn=a SstHttpConnection
nread=0
SstTcpTransport(SstConnectiveTransport)>>#getNextIncomingConnection
self=SstTcpTransport(SstLocalEndpoint(http://:9345/))
connection=nil
SstLocalEndpoint>>#getNextIncomingConnection
self=SstLocalEndpoint(http://:9345/)
SstInvocationHandler>>#retrieveAndProcessNextRequest
self=SstInvocationHandler(http://:9345/)
connection=nil
innerIncomingWorkBlock=nil
incomingWorkBlock=nil
[] in SstInvocationHandler>>#serverProcessBlock
self=SstInvocationHandler(http://:9345/)
result=SstInvocationHandler(http://:9345/)
BlockContextTemplate(Block)>>#valueWithErrorHandler:oldHandler:onReturnDo:
self=[] in SstInvocationHandler>>#serverProcessBlock
handler=[] in Block>>#when:do:exitWith:retryReturn:
oldHandler=nil
completionBlock=[]
BlockContextTemplate(Block)>>#when:do:exitWith:retryReturn:
self=[] in SstInvocationHandler>>#serverProcessBlock
exception=Exception: (ExError) An error has occurred.
handlerBlock=[] in SstInvocationHandler>>#defaultServerExceptionHandler
exitBlock=[] in Block>>#when:do:
knownResult=an Object
retryBlock=[] in Block>>#when:do:exitWith:retryReturn:
handler=[] in Block>>#when:do:exitWith:retryReturn:
oldHandler=nil
BlockContextTemplate(Block)>>#when:do:
self=[] in SstInvocationHandler>>#serverProcessBlock
exception=Exception: (ExError) An error has occurred.
handlerBlock=[] in SstInvocationHandler>>#defaultServerExceptionHandler
knownResult=an Object
result=nil
[] in SstInvocationHandler>>#serverProcessBlock
self=SstInvocationHandler(http://:9345/)
result=SstInvocationHandler(http://:9345/)
[] in Process>>#executeBlock:withArguments:
self=Process:HTTP Server Process for: http://:9345/ (1){suspended,3}
aBlock=[] in SstInvocationHandler>>#serverProcessBlock
args=()
Process>>#executeBlock:withArguments:
self=Process:HTTP Server Process for: http://:9345/ (1){suspended,3}
aBlock=[] in SstInvocationHandler>>#serverProcessBlock
args=()
Process>>#newProcessOn:stackSize:withArguments:named:
self=Process:HTTP Server Process for: http://:9345/ (1){suspended,3}
aBlock=[] in SstInvocationHandler>>#serverProcessBlock
stackSize=1024
args=()
procName='19585'
==============<STACK TRACE ENDS>=============
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Fri Nov 12, 2010 2:29 am

Ok, Apache logs errors in this case .... that means, that the Apache has trouble with the VA server ...

Fri Nov 12 10:51:00 2010] [error] [client 192.168.70.160] (OS 10054)Eine vorhandene Verbindung wurde vom Remotehost geschlossen. : proxy: error reading status line from remote server 127.0.0.1:9345
[Fri Nov 12 10:51:00 2010] [error] [client 192.168.70.160] (OS 10054)Eine vorhandene Verbindung wurde vom Remotehost geschlossen. : proxy: error reading status line from remote server 127.0.0.1:9345
[Fri Nov 12 10:51:00 2010] [error] [client 192.168.70.160] proxy: Error reading from remote server returned by /esystem
[Fri Nov 12 10:51:00 2010] [error] [client 192.168.70.160] proxy: Error reading from remote server returned by /esystem


marten wrote:
PS1: Or an Apache configuration problem ?
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby jtuchel » Fri Nov 12, 2010 4:28 am

Marten,

I'd say the way you implemented the reload is absolutely correct from an HTTP protocol standpoint. I suspect this might cause troubles because it resends the same session/continuation keys to the server, which is probably not a good idea in Seaside. It should work, but it might not be the best idea. Not sure it works in a Seaside without continuation support, though.

Speaking of the Browser rendering source code instead of a page: Did yu verify there was an HTTP request issued to the server, or was the result delivered from some Apache cache?

If I understand correctly, you try to solve the wrong problem with Apache. If you Smalltalk app is too busy processing JSON (I suspect that's due to the fact that you wait for the C Library you use), I see no added value in putting it behind Apache.

Anyways: I think it is a good idea to keep Apache out of the game for normal testing/development work for two reasons:
* You can be sure the problem's within your Smalltalk Image by reducing the complexity
* In development there is not much gain in load balancing

So I'd test with Apache from time to time, but not use it for development or debugging.
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby TriSebastian » Fri Nov 12, 2010 5:34 am

Hi Marten,

I assume Jaochim is right.

I implemented some kind of streaming chart with the jWuery update process under VAST 8.0.1 and this ran properly over a whole night.

I didn't use it with VSAt 8.0.2,yet. Did you try your test with 8.0.1, too?

Sebastian
TriSebastian
 
Posts: 76
Joined: Sun Jul 20, 2008 9:40 pm
Location: Nanaimo, BC, Canada

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Fri Nov 12, 2010 6:13 am

Hello Joachim,

* package early, package often to get the problems early .... therefore use Apache early to know the problems.

* I know, that using Apache will not speed up my VASmalltalk system

* later on I will check for the load balancer by using Apache

* I do not test with my more complex application any more, but use a much more simplier renderingmethod

Code: Select all
renderContentOn: html
   html text: DateAndTime now printString.
   html paragraph: 'Hello World from Seaside.'.
   html paragraph: [
      html text: 'To learn more about Seaside components follow the link to the book: '.
      html anchor
         url: 'http://book.seaside.st/book/fundamentals/rendering-components';
         with: 'Dynamic Web Development with Seaside'.
      html text: '.' ].
   1 to: 10000 do: [ :anIndex | html break. html anchor callback: [ ] ; with: 'www.heise.de'  ].


with a refresh time of 1 seconds - actually the error happens much less, but it happens. I use Chrome, open three tabs and let the browser do the work. Perhaps 30 minutes I have to let them run and I get errors in this simple configuration. This only happens in an Apache configuration.

jtuchel wrote:Marten,

If I understand correctly, you try to solve the wrong problem with Apache. If you Smalltalk app is too busy processing JSON (I suspect that's due to the fact that you wait for the C Library you use), I see no added value in putting it behind Apache.

Anyways: I think it is a good idea to keep Apache out of the game for normal testing/development work for two reasons:
* You can be sure the problem's within your Smalltalk Image by reducing the complexity
* In development there is not much gain in load balancing

So I'd test with Apache from time to time, but not use it for development or debugging.
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby jtuchel » Fri Nov 12, 2010 1:46 pm

Hi Marten,

that's interesting. I guess the error you mention is that #flush problem you described earlier...?

Just to see if it's a problem of "file" sizes (10000 times 'www.heise.de' with all that <a href=... stuff around it will probably make your pages quite big):
Do you see the same problem if you leave out the 10000 links?

Maybe I am on the wrong track, but I guess we could narrow the problem down a bit by trying to isolate several possible reasons...

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Fri Nov 12, 2010 1:55 pm

marten wrote:Then the browser with the autoload running stops updating and shows only the sourcecode of that page.


Ok, at least I know, why the source code is displayed. I do not know how the system comes into this situation but at least the first seps are done.

For a new page in general Seaside answers to the client a "302 Moved Temporarily". In this header Seaside tells the browser to try a new URL to get the new content. The source code for such an answer is:

HTTP/1.1 302 Moved Temporarily
Date: Fri, 12 Nov 2010 22:38:25 GMT
Server: Seaside Servlet Server - VA Smalltalk V8.0.2 (WIN32s): Seaside 3.0beta1
Content-Type: text/html;charset=utf-8
Location: /esystem?_s=CFG2YMBJTNwQGrVJ&_k=3Y3wNMBVKCn8df7s
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive


The browser reads the new location url and makes a new get-request and finally gets the content of the page it has to display.

If all the stuff is working the header of this get-request looks like (client to seaside):

GET /esystem?_s=T6TZLNsdF3qStvz-&_k=HU4sptCSbgyggfT6 HTTP/1.1
Host: lokma
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://lokma/esystem?_s=T6TZLNsdF3qStvz ... _fhFwwfsT_


and the answer-header from VA looks like:

HTTP/1.1 200 OK
Date: Fri, 12 Nov 2010 22:08:24 GMT
Server: Seaside Servlet Server - VA Smalltalk V8.0.2 (WIN32s): Seaside 3.0beta1
Content-Type: text/html;charset=utf-8
Content-Length: 17174
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive


Now, if I reach the error case the answer-header looks quite different:

HTTP/1.1 200 OK
Date: Fri, 12 Nov 2010 21:05:20 GMT
Content-Length: 17174
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/plain


And here we are: the answer seems to be quite different from that one in the normal way. The browser sees now a text/plain and the browser shows the source code of page.

That's my info ...
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Fri Nov 12, 2010 2:00 pm

jtuchel wrote:Do you see the same problem if you leave out the 10000 links?


No, I made that page of that size to get a better chance of producing this error and to put VA under really heavy pressure.

Be aware of the fact, that I actually have two errors described in this thread: page sources displayed as ASCII text and low-level socket problems.
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby jtuchel » Fri Nov 12, 2010 2:06 pm

Marten,

one thing I do from time to time when I have the feeling a problem I have could be related to VAST rather than Seaside or my coding (guess about the percentages ;-) ) is that I use a Pharo Seaside Image and try the same thing there. It helped me learn a lot about my assumptions on how Seaside works ;-)

Also, since it seems the erronous answer came from "somewhere else" than the Seaside render cycle, could you verify if your render method actually ran? Is this with or without Apache? What Apache modules are configured?

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby jtuchel » Fri Nov 12, 2010 2:10 pm

marten wrote:
jtuchel wrote:Do you see the same problem if you leave out the 10000 links?

No, I made that page of that size to get a better chance of producing this error and to put VA under really heavy pressure.


Okay, so we may see some size problem here. Maybe you can try and find out at which size the problem shows up. Is it 32K, 128K, 256K? I wouldn't be surprised if that's an SST-Problem.

Joachim


Ah, and BTW, even if the page is sent as text/ascii, there still should be an HTTP header field for the reload if it came from Seaside...
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby jtuchel » Thu Nov 18, 2010 11:29 pm

Marten,

I've seen you've blogged ([url]http://schrievkrom.wordpress.com/2010/11/13/vasmalltalk-seaside-memory-rendering-and-apache/[/url]) about the problem and found that the html page issue was caused by an Apache misconfiguration. Could you post a few details abut this?

Any news on you connection loss problems with #flush?

Also, you mention memory growth problems (in which VAST performs better than Pharo). Did you have any progress with these?

Joachim
jtuchel
[|]
 
Posts: 245
Joined: Fri Oct 05, 2007 1:05 am
Location: Ludwigsburg, Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Fri Nov 19, 2010 12:00 am

No - it is NOT a misconfiguration of Apache. I can get rid of this problems with the help of Apache - but the problem itselfs seems to be a communication problem between VA and Apache with an answer header. I've noticed the same behaviour (once - in a different way), when the VA Seaside code produces an exception and the exception information is written into the page content (!). Then I got only parts of the HTML page source and my exception description as ASCII text (text/plain) shown in my browser.

No - the connection loss problems are still there and mainly then, when I do stress tests.

No - the problem is the same on Pharo. On the Seaside developer list I got one answer, that this is an unrealistic, theoretical problem - but there was one person, who said, that he thinks that sessions are getting NOT automatically expired - as expected. But this should not be my problem. I've opened a bug report (http://code.google.com/p/seaside/issues/detail?id=611#c2) - but get no answer yet. The example application to show this behaviour is very simple. Under VA I looked at my instances for specific classes and if I remember correctly I have a huge amount of anchor instances in my images.

jtuchel wrote:Marten,

I've seen you've blogged (http://schrievkrom.wordpress.com/2010/11/13/vasmalltalk-seaside-memory-rendering-and-apache/) about the problem and found that the html page issue was caused by an Apache misconfiguration. Could you post a few details abut this?

Any news on you connection loss problems with #flush?

Also, you mention memory growth problems (in which VAST performs better than Pharo). Did you have any progress with these?

Joachim
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: [8.0.2] Autorefresh of WWW-Page with Seaside ...

Postby marten » Sun Dec 19, 2010 3:57 am

Just for your information: with Seaside 3.0.3 this problem seems to be solved - or at least a solution has been named.

marten wrote:No - the problem is the same on Pharo. On the Seaside developer list I got one answer, that this is an unrealistic, theoretical problem - but there was one person, who said, that he thinks that sessions are getting NOT automatically expired - as expected. But this should not be my problem. I've opened a bug report (http://code.google.com/p/seaside/issues/detail?id=611#c2) - but get no answer yet. The example application to show this behaviour is very simple. Under VA I looked at my instances for specific classes and if I remember correctly I have a huge amount of anchor instances in my images.
Marten Feldtmann, Principal Smalltalk User, Private
SkypeMe callto://marten.feldtmann
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany


Return to VA Smalltalk 7.0, 7.5 & 8.0

Who is online

Users browsing this forum: Google [Bot] and 1 guest

cron