Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Fast demands gives err 500
#1
Hi,
I have an intraweb application that runs smooth under normal condition, but under fast demands it sends a "internal error 500" to the clients.

The error arises when using a custom handler (e.g. iw.content.xml look alike) after this is called rapidly (Called by an external program, 5 times typically). If the same operation is done one at the time (slow) there is no problem.

I suspect that it might be a memory error, but have no clues.

Is it possible to release the custom handler after use (freeing the memory) or is this done automatically by intraweb?

Will it help to insert a small time delay between each call?

Sorry if this is a bit "fluffy", but i have no idea where to set in for a solution

regards ib
Reply
#2
Hi ib.

What versions of IW and Delphi?

If you are using the Personal version you might be hitting the 5 session limit. Custom handlers do create a small session (using a session ID) while they are active. They are killed quickly, but maybe not before your calls end. So, it would be helpful to know your versions.

Thanks,
Dan
Reply
#3
Hi,

As Dan pointed out above, which version of IW and Delphi are you running?

Also, it is not clear that the calls to your content handler are targeted to the same session or different sessions. Is your session control based on cookies? If so, are you sending the cookies correctly to the server?
Reply
#4
(06-03-2019, 02:19 AM)Alexandre Machado Wrote: Hi,

As Dan pointed out above, which version of IW and Delphi are you running?

Also, it is not clear that the calls to your content handler are targeted to the same session or different sessions. Is your session control based on cookies? If so, are you sending the cookies correctly to the server?

Sorry for the missing info.

Delphi XE 5 (the application runs on an old windows XP)
intraweb version is 14.0.52
Mode: SA
Not using cookies
Database: Firedac/mysql

The handler is an API for an external web application. The handler produces a label (for shipping goods). The problem arises when the client program does a bulk print (e.g. sends for instance 10 individual calls for 10 labels to the handler within a second). The handler produces a PDF label, writes this to disk and returns a string to the calling program, that contains the web-address of the PDF file for each of the 10 calls.

I have tried to lock the session (asession.lock   .handler-code...   asession.unlock), 
tried to delay each the session (makes no sense if the session is not locked, as it is timer based)

What I need is some way to delay the jobs until the current client job is terminated. The documentation for intraweb states that the 10 jobs is queued and executed one at the time, but somehow the process does not wait until all processes is terminated. It seems as it is the database process that is not done.

The problem is probably a firedac/mysql issues (blocking versus non-blocking), but the quick and dirty way to solve the problem is to delay each call in Intraweb.

Regards ib
Reply
#5
(06-03-2019, 03:53 AM)ib elfving Wrote:
(06-03-2019, 02:19 AM)Alexandre Machado Wrote: Hi,

As Dan pointed out above, which version of IW and Delphi are you running?

Also, it is not clear that the calls to your content handler are targeted to the same session or different sessions. Is your session control based on cookies? If so, are you sending the cookies correctly to the server?

Sorry for the missing info.

Delphi XE 5 (the application runs on an old windows XP)
intraweb version is 14.0.52
Mode: SA
Not using cookies
Database: Firedac/mysql

The handler is an API for an external web application. The handler produces a label (for shipping goods). The problem arises when the client program does a bulk print (e.g. sends for instance 10 individual calls for 10 labels to the handler within a second). The handler produces a PDF label, writes this to disk and returns a string to the calling program, that contains the web-address of the PDF file for each of the 10 calls.

I have tried to lock the session (asession.lock   .handler-code...   asession.unlock), 
tried to delay each the session (makes no sense if the session is not locked, as it is timer based)

What I need is some way to delay the jobs until the current client job is terminated. The documentation for intraweb states that the 10 jobs is queued and executed one at the time, but somehow the process does not wait until all processes is terminated. It seems as it is the database process that is not done.

The problem is probably a firedac/mysql issues (blocking versus non-blocking), but the quick and dirty way to solve the problem is to delay each call in Intraweb.

Regards ib

If you based your code on IW.Content.XML.pas (from one of our demos) each call should start a new session. Each one should run independently without any issues, as long as your code is also thread safe. Is it?

In that regard, you should not share any global objects (e.g. a Database connection). If you share some code it would be easier to spot any potential problems....
Reply
#6
(06-03-2019, 09:30 AM)Alexandre Machado Wrote:
(06-03-2019, 03:53 AM)ib elfving Wrote:
(06-03-2019, 02:19 AM)Alexandre Machado Wrote: Hi,

As Dan pointed out above, which version of IW and Delphi are you running?

Also, it is not clear that the calls to your content handler are targeted to the same session or different sessions. Is your session control based on cookies? If so, are you sending the cookies correctly to the server?

Sorry for the missing info.

Delphi XE 5 (the application runs on an old windows XP)
intraweb version is 14.0.52
Mode: SA
Not using cookies
Database: Firedac/mysql

The handler is an API for an external web application. The handler produces a label (for shipping goods). The problem arises when the client program does a bulk print (e.g. sends for instance 10 individual calls for 10 labels to the handler within a second). The handler produces a PDF label, writes this to disk and returns a string to the calling program, that contains the web-address of the PDF file for each of the 10 calls.

I have tried to lock the session (asession.lock   .handler-code...   asession.unlock), 
tried to delay each the session (makes no sense if the session is not locked, as it is timer based)

What I need is some way to delay the jobs until the current client job is terminated. The documentation for intraweb states that the 10 jobs is queued and executed one at the time, but somehow the process does not wait until all processes is terminated. It seems as it is the database process that is not done.

The problem is probably a firedac/mysql issues (blocking versus non-blocking), but the quick and dirty way to solve the problem is to delay each call in Intraweb.

Regards ib

If you based your code on IW.Content.XML.pas (from one of our demos) each call should start a new session. Each one should run independently without any issues, as long as your code is also thread safe. Is it?

In that regard, you should not share any global objects (e.g. a Database connection). If you share some code it would be easier to spot any potential problems....

I am not using any global IW-variables. My database (except for the firedac database connection) is accessed through variables in the usersession, so this should isolate the individual session data from each other, but I am using an ordinary delphi-unit for business routines. I will check this for variables that might cause the conflict, maybe try to move the database connection to the usersession instead to see if this makes a change.

Still - is it possible in an easy way to delay each call to the handler - e.g. 10 request arrives to the SA within 1 sec, but is "delay" so that each request starts with a delay of for instance 1 sec. (request 1 start at 1 sec, request 2 starts at 2 sec .. request 10 start at 10 sec)

regards ib
Reply
#7
I have two suggestions

1. FOR TESTING ONLY: Counterintuitive but what about implementing a block so that only one connection is allowed as a time.
2. I had a similiar but not the same problem. If you app is a multi-tenanted database then you need to assign the dataset connection at runtime

Hope this helps
Reply
#8
I should have asked which edition (Evaluation, Personal, Standard, Ultimate) when I asked about version.

https://www.atozed.com/intraweb/features/

Dan
Reply
#9
(06-03-2019, 09:24 PM)zsleo Wrote: I have two suggestions

1. FOR TESTING ONLY: Counterintuitive but what about implementing a block so that only one connection is allowed as a time.
2. I had a similiar but not the same problem. If you app is a multi-tenanted database then you need to assign the dataset connection at runtime

Hope this helps

Also make sure your uses clause includes   IWRtlFix,
Reply
#10
(06-03-2019, 12:29 PM)ib elfving Wrote: I am not using any global IW-variables. My database (except for the firedac database connection) is accessed through variables in the usersession, so this should isolate the individual session data from each other, but I am using an ordinary delphi-unit for business routines. I will check this for variables that might cause the conflict, maybe try to move the database connection to the usersession instead to see if this makes a change.

Still - is it possible in an easy way to delay each call to the handler - e.g. 10 request arrives to the SA within 1 sec, but is "delay" so that each request starts with a delay of for instance 1 sec. (request 1 start at 1 sec, request 2 starts at 2 sec .. request 10 start at 10 sec)

You can serialize them using a critical section or a semaphore, but I find it weird that you want (or need) to do so. As long as you are not sharing things between threads you should be able to run "N" content handlers in parallel with no issues.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)