| Author |
EAServer (Jaguar) component memory problems
|
|
| julian 2005-04-12, 11:25 am |
| Hello
I have this problem ...
I am writing an easerver component (in PowerBuilder) that reads one table and
returns the read data as result set (from GetResutlSet) or blob (from
GetFullState).
The problem is that when the table is too big (say around 130 000 rows
x 75 columns) EAServer crashes (issues messagebox ?!?!). I think this is a
memory problem. If the component allocates lots of memory (say around 300MB)
there was the same problem.
I tried Easerver 4.2.2 and 5.2.
Easerver 5.2 do not crash but sometimes the component's method never
returns, component is never destroyed, and the memory remains allocated (and
never freed).
If my component uses only 30MB memory, but clients are more than 10
then the same thing happens.
Is there any workarounds to solve this problem?
How to know how much memory I can use? How to write a
safe component that will work properly?
Why EAServer can't always manage those cases?
---== Posted via the PFCGuide Web Newsreader ==---
http://www.pfcguide.com/_newsgroups/group_list.asp
| |
| Marty Jones 2005-04-12, 11:25 am |
| I will take a stab at this one. I guess the biggest issue you have is
trying to return 130,000 rows in a resultset. Why on earth would you do
such a thing? The calling client will never sift through that much data and
if it is a backend process that needs the data there are several better ways
to get the data to that process that accross IIOP. You didn't specify how
much memory is on the machine that is running the Jaguar machine so I can't
guess as to why you are running out of memory.
Can you shed some light on why you are trying to return so much data to a
calling client?
"julian" <spamofju@mail.bg> wrote in message news:425be7ba@forums
-1-dub...
> Hello
>
>
> I have this problem ...
>
>
> I am writing an easerver component (in PowerBuilder) that reads one table
> and
> returns the read data as result set (from GetResutlSet) or blob (from
> GetFullState).
> The problem is that when the table is too big (say around 130 000 rows
> x 75 columns) EAServer crashes (issues messagebox ?!?!). I think this is a
> memory problem. If the component allocates lots of memory (say around
> 300MB)
> there was the same problem.
>
>
> I tried Easerver 4.2.2 and 5.2.
>
>
> Easerver 5.2 do not crash but sometimes the component's method never
> returns, component is never destroyed, and the memory remains allocated
> (and
> never freed).
>
>
> If my component uses only 30MB memory, but clients are more than 10
> then the same thing happens.
>
> Is there any workarounds to solve this problem?
>
> How to know how much memory I can use? How to write a
> safe component that will work properly?
>
> Why EAServer can't always manage those cases?
>
>
>
> ---== Posted via the PFCGuide Web Newsreader ==---
> http://www.pfcguide.com/_newsgroups/group_list.asp
| |
| Jim Egan 2005-04-12, 8:24 pm |
| spamofju@mail.bg wrote...
> Hello
>
>
> I have this problem ...
>
>
> I am writing an easerver component (in PowerBuilder) that reads one table and
> returns the read data as result set (from GetResutlSet) or blob (from
> GetFullState).
> The problem is that when the table is too big (say around 130 000 rows
> x 75 columns) EAServer crashes (issues messagebox ?!?!). I think this is a
> memory problem. If the component allocates lots of memory (say around 300MB)
> there was the same problem.
>
>
> I tried Easerver 4.2.2 and 5.2.
>
>
> Easerver 5.2 do not crash but sometimes the component's method never
> returns, component is never destroyed, and the memory remains allocated (and
> never freed).
>
>
> If my component uses only 30MB memory, but clients are more than 10
> then the same thing happens.
>
> Is there any workarounds to solve this problem?
>
> How to know how much memory I can use? How to write a
> safe component that will work properly?
>
> Why EAServer can't always manage those cases?
You are returned WAY too much data. Either set the DW to use rows per page or perhaps you
should consider printing the results to a PDF on the server and then sending the PDF back
to the client instead of the HTML DW.
--
Jim Egan [TeamSybase]
Sybase product enhancement requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement
| |
| Adam Simmonds [TeamSybase] 2005-04-12, 8:24 pm |
| Jim Egan wrote:
> spamofju@mail.bg wrote...
>
>
>
> You are returned WAY too much data. Either set the DW to use rows per page or perhaps you
> should consider printing the results to a PDF on the server and then sending the PDF back
> to the client instead of the HTML DW.
Was the OP using the HTMLDW??? <vbg>
| |
| Jim Egan 2005-04-14, 3:24 am |
| asimmond@remove.mail.usyd.edu.au wrote...
>
> Was the OP using the HTMLDW??? <vbg>
>
OK, he wasn't. But, it's still way too much data to return to a browser.
--
Jim Egan [TeamSybase]
Sybase product enhancement requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement
| |
| Adam Simmonds [TeamSybase] 2005-04-14, 3:24 am |
| Jim Egan wrote:
> asimmond@remove.mail.usyd.edu.au wrote...
>
>
> OK, he wasn't. But, it's still way too much data to return to a browser.
Yep, WAYYYYYY too much. IE hits problems when it gets too many controls.
Mozilla/Firefox doesnt seem to get too worried about lots of data though.
| |
| Jonathan Baker [Sybase] 2005-04-14, 1:24 pm |
| Google did a study (based on thier hit rates). Over 80% of the people
searching used the first page (only) and that contains about 10 entries.
The next 12% looked at the second page. Only about 1% get past page
5 (and the numbers exponentially decrease to page 20, with like .0001%
after 20).
So, yes, 100K rows of data is overkill - and most likely wasting bandwidth.
Jonathan
Adam Simmonds [TeamSybase] wrote:
> Jim Egan wrote:
>
>
>
> Yep, WAYYYYYY too much. IE hits problems when it gets too many controls.
> Mozilla/Firefox doesnt seem to get too worried about lots of data though.
| |
| Dean Jones 2005-04-15, 8:24 pm |
| I have seen customers retrieve 1 million rows into a datastore. I don't
suggest it, but it can be done.
Did you modify ds.Object.DataWindow.StoragePageSize
--
Dean Jones [TeamSybase]
CEO
Certified PowerBuilder Developer
www.powerobjects.com
(612) 339-3355 ext 112
Don't miss this years seminar http://seminar.powerobjects.com
"Marty Jones" < marty_jones@dailyacc
ess.com> wrote in message
news:425bebc3$1@foru
ms-1-dub...
>I will take a stab at this one. I guess the biggest issue you have is
>trying to return 130,000 rows in a resultset. Why on earth would you do
>such a thing? The calling client will never sift through that much data
>and if it is a backend process that needs the data there are several better
>ways to get the data to that process that accross IIOP. You didn't specify
>how much memory is on the machine that is running the Jaguar machine so I
>can't guess as to why you are running out of memory.
>
> Can you shed some light on why you are trying to return so much data to a
> calling client?
>
> "julian" <spamofju@mail.bg> wrote in message news:425be7ba@forums
-1-dub...
>
>
| |
| Jim Egan 2005-04-15, 8:24 pm |
| last_name_first_init
ial@sybase.com wrote...
> Google did a study (based on thier hit rates). Over 80% of the people
> searching used the first page (only) and that contains about 10 entries.
> The next 12% looked at the second page. Only about 1% get past page
> 5 (and the numbers exponentially decrease to page 20, with like .0001%
> after 20).
>
> So, yes, 100K rows of data is overkill - and most likely wasting bandwidth.
I rarely go to a second page. If I don't find what I wanted on the first page then I
usually need to revise my search criteria. But I also allow 50 results per page I think.
--
Jim Egan [TeamSybase]
Sybase product enhancement requests:
http://www.isug.com/cgi-bin/ISUG2/submit_enhancement
|
|
|
|