|
|
Home » Developing U++ » U++ Developers corner » Skylark reaching "beta" status, first 6 chapters of tutorial available..
|
Re: Skylark reaching "beta" status, first 6 chapters of tutorial available.. [message #36813 is a reply to message #36800] |
Sun, 08 July 2012 15:50   |
|
Hi Mirek,
Great work, the tutorials almost made me want to write a web-app 
However, I found a little problem... Out of curiosity, I tried to run ab (Apache Benchmark) on Skylark based application, namely tutorial/Skylark04. It works great, but only sometimes. After a (variable) number of requests, the application fails with assert:Log: | ****************** ASSERT FAILED: Assertion failed in /home/h/upp-production/uppsrc/Core/String.cpp, line 38
rc->refcount > 0
LastErrorMessage: No such file or directory
|
Backtrace: | Upp::AssertFailed (file=0x83fdb2f "/home/h/upp-production/uppsrc/Core/String.cpp", line=38, cond=0x84016ea "rc->refcount > 0") at /home/h/upp-production/uppsrc/Core/Util.cpp:110
Upp::String0::LFree (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/String.cpp:38
Upp::String0::Free (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/String.h:226
Upp::String0::~String0 (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/String.h:303
Upp::AString<Upp::String0>::~AString (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/String.h:34
Upp::Moveable<Upp::String, Upp::AString<Upp::String0> >::~Moveable (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/Topt.h:195
Upp::String::~String (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/String.h:306
Upp::String::~String (this=0xb426bf18) at /home/h/upp-production/uppsrc/Core/String.h:306
Upp::RawHtmlText::~RawHtmlText (this=0xb426bf18) at /home/h/upp-production/uppsrc/Skylark/Witz.h:14
Upp::RawHtmlText::~RawHtmlText (this=0xb426bf18) at /home/h/upp-production/uppsrc/Skylark/Witz.h:14
Upp::RawValueRep<Upp::RawHtmlText>::~RawValueRep (this=0xb426bf10) at /home/h/upp-production/uppsrc/Core/Value.hpp:70
Upp::RawValueRep<Upp::RawHtmlText>::~RawValueRep (this=0xb426bf10) at /home/h/upp-production/uppsrc/Core/Value.hpp:70
Upp::RawValueRep<Upp::RawHtmlText>::~RawValueRep (this=0xb426bf10) at /home/h/upp-production/uppsrc/Core/Value.hpp:70
Upp::Value::Void::Release (this=0xb426bf10) at /home/h/upp-production/uppsrc/Core/Value.h:85
Upp::Value::RefRelease (this=0xb626fa68) at /home/h/upp-production/uppsrc/Core/Value.cpp:25
Upp::Value::~Value (this=0xb626fa68) at /home/h/upp-production/uppsrc/Core/Value.h:239
Upp::Value::~Value (this=0xb626fa68) at /home/h/upp-production/uppsrc/Core/Value.h:239
Upp::Compiler::ExeBlock::Eval (this=0xb41a4ef0, x=...) at /home/h/upp-production/uppsrc/Skylark/Exe.cpp:386
Upp::Render (exe=..., r=0xb62706a0, var=...) at /home/h/upp-production/uppsrc/Skylark/Exe.cpp:395
Upp::Http::RenderResult (this=0xb62706a0, template_name=0x83fbfaa "Skylark04/index") at /home/h/upp-production/uppsrc/Skylark/Http.cpp:290
HomePage (http=...) at /home/h/upp-production/tutorial/Skylark04/main.cpp:7
Upp::Http::Dispatch (this=0xb62706a0, socket=...) at /home/h/upp-production/uppsrc/Skylark/Dispatch.cpp:327
Upp::SkylarkApp::RunThread (this=0xbffff3d8) at /home/h/upp-production/uppsrc/Skylark/App.cpp:67
Upp::SkylarkApp::WorkThread (this=0xbffff3d8) at /home/h/upp-production/uppsrc/Skylark/App.cpp:32
Upp::SkylarkApp::ThreadRun (this=0xbffff3d8) at /home/h/upp-production/uppsrc/Skylark/App.cpp:37
Upp::CallbackMethodAction<Upp::SkylarkApp, void (Upp::SkylarkApp::*)()>::Execute (this=0xb7fda7a0) at /home/h/upp-production/uppsrc/Core/Callback0.h:24
Upp::Callback::Execute (this=0xb7fd81b0) at /home/h/upp-production/uppsrc/Core/Callback.cpp:7
Upp::Callback::operator() (this=0xb7fd81b0) at /home/h/upp-production/uppsrc/Core/Cbgen.h:32
Upp::sThreadRoutine (arg=0xb7fd81b0) at /home/h/upp-production/uppsrc/Core/Mt.cpp:75
start_thread () from /lib/libpthread.so.0
clone () from /lib/libc.so.6
|
I guess there is some concurrency issue... To reproduce, you can run ab -n 1000 -c 20 http://127.0.0.1:8001/myapp .
And BTW: there is a lot of DLOGs and DDUMPs scattered in the skylark code, so it is not directly compilable in release mode 
Best regards,
Honza
|
|
|
|
Re: Skylark reaching "beta" status, first 6 chapters of tutorial available.. [message #36816 is a reply to message #36813] |
Sun, 08 July 2012 20:59   |
 |
mirek
Messages: 14256 Registered: November 2005
|
Ultimate Member |
|
|
dolik.rce wrote on Sun, 08 July 2012 09:50 | Hi Mirek,
Great work, the tutorials almost made me want to write a web-app 
However, I found a little problem... Out of curiosity, I tried to run ab (Apache Benchmark) on Skylark based application, namely tutorial/Skylark04. It works great, but only sometimes. After a (variable) number of requests, the application fails with assert:
|
Should be fixed, together with three other bugs revealed by 'ab'....
Now tested with one million ab requests without failing.
Also, DLOGs removed, it should be now possible to compile release mode.
Mirek
|
|
|
|
|
|
|
Re: Skylark reaching "beta" status, first 6 chapters of tutorial available.. [message #36826 is a reply to message #36825] |
Mon, 09 July 2012 20:42   |
 |
mirek
Messages: 14256 Registered: November 2005
|
Ultimate Member |
|
|
zsolt wrote on Mon, 09 July 2012 13:43 |
mirek wrote on Mon, 09 July 2012 19:28 |
OK, one possible issue: User could provide some value before is is created in session and it could have been mistakingly considered a session value...
|
Yes, this can be a real danger in a large project with a lot of programmers (many of them can be very sloppy).
Don't you think, it would be more safe to separate session and post variables at least based on some configuration option?
|
Actually, I was a little bit afraid when introducing this "shared variable space", but decided to give it a try... anyway, I guess php $_REQUEST discussion applies here too (yep, cookies go there as well so we have to take some measures. Even back when introducing the operator[], the option was to differentiate by first character of id.
So http[":var"] would be session, http["@var"] cookie and http["var"] either GET or POST (I guess not need to split those, as handlers react only to GET or POST, never both). GET and POST values with ':' and '@' at the start would be explicitly disallowed (and ignored).
The reason why not simply go with some Http::GetSession is that this way, some common processing is possible (e.g. Http::Int(const char *id)).
Do you see some catch in this remake?
Mirek
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 29 19:51:59 CEST 2025
Total time taken to generate the page: 0.00682 seconds
|
|
|