Problem with OpenROAD Application being "Killed" under Windows 7

[Martin.B...@hse.gsi.gov.uk]

Hello all,

 

We have recently upgraded our PCs to Windows 7 and a few of our users are reporting problems running some of our reporting applications.  Some of the queries processed by these applications can take a long time to run (up to 30 minutes).  Under windows XP, the interface would change to “Not Responding”, but the app carried on running and when all the data aggregation had completed the application “came back to life”, and displayed the results screen / generated the report output.

 

Under Windows 7, users are reporting that the application changes to “Not Responding” very quickly and then after a while the application just closes – we assume Windows thinks the application has died and is terminating the w4glrun process.

 

Has anyone else come across this, and do you have any suggestions on how to fix this problem?

 

We are currently using Ingres/Net 9.2 and OpenROAD 5.0.

 

Many thanks,

 

Martin Bloomfield
Application Developer & Database Administrator
IT Solutions Development
Business Services Division
Health and Safety Executive
YORK

www.hse.gov.uk

Follow HSE on Twitter @H_S_E

 

*****************************************************************************************************************

Please note : Incoming and outgoing email messages are routinely monitored for compliance with our policy on the use of electronic communications and may be automatically logged, monitored and / or recorded for lawful purposes by the GSI service provider.

 

Interested in Occupational Health and Safety information?

Please visit the HSE website at the following address to keep yourself up to date

 

www.hse.gov.uk

 

*****************************************************************************************************************

 

 

The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Vodafone in partnership with Symantec. (CCTM Certificate Number 2009/09/0052.) This email has been certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

[Paul A.]

Martin, having a UI system running queries that last 30 minutes and lock up their system in the meantime is really poor.

I used to have a similar problem on a system running reports that took a long time to amalgamate the data to be printed.

At that time we created a queue system to submit the job to and had two dedicated PCs running 24/7 processing the submitted jobs from the queue. It could be done even better on a unix box.

Basically we had a job that would normally sleep, but periodically (about once every minute) it looked at the queue and ran the job.

You could build a similar system that would allow the user to carry on working and be notified when the results are ready.

Your users must be so frustrated.

Paul

--
You received this message because you are subscribed to the Google Groups "OpenROAD Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openroad-user...@googlegroups.com.
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/57B7A7598ACE5348B646796AADE237E331E78E48%40VBTLMBX01.hse.int.
For more options, visit https://groups.google.com/d/optout.

[Matt V Turner]

All,

 

We have a similar issue with screens that are actively feeding back progress on a process. If the user switches focus to another window to read an email etc then the OR screen is marked as ‘not responding’ and there does not then appear to be a way (programmatically or otherwise) to get the screen to refresh until the process completes and users are understandably tempted to kill processes that appear to have stalled.

 

I would be grateful for any suggestions to counteract this.

 

 

Regards

 

Matt Turner

Application Support & Development Analyst

University of Hull

Hull, HU6 7RX, UK

http://www.hull.ac.uk/

01482 466504

To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/5502BD2D.2090906%40ipauland.com.

[Sidney]

Hi Martin

just a thought but maybe the problem is that OpenRoad 5.0 is not certified on Windows 7

take a look at the readme.html

OpenROAD 2006 SP1 (OR 5.0/0804 (int.w32/00)) is supported on the following Microsoft Windows platforms:

    Windows Server 2008 or Windows Vista with UAC turned off

    Windows 2003

    Windows XP

    Windows 2000

Cheers

Sidney

Sidney...@actian.com | Principal Support Engineer | 1800 614 435 | Location: Brisbane [GMT +10]

[Paul A.]

I think anyone using OR is going to get a 'bad press' if they submit the user to a dead screen because of long-running, synchronous queries.

The only way I know to prevent this is to implement a queue serviced by a remote process and have the UI itself monitor the status of it's job in the queue rather than be actively processing the transaction.

Commonly in non-OR based systems, they process database interactions asynchronously and don't lock up the UI because they effectively use a callback mechanism. That is a far better way to work.

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/C9A8AE8DF274DC4EBEE1752A5F780C502B0D7780%40EX3-VM.adir.hull.ac.uk.

For more options, visit https://groups.google.com/d/optout.

**************************************************
To view the terms under which this email is 
distributed, please go to 
http://www2.hull.ac.uk/legal/disclaimer.aspx
**************************************************

[Paul A.]

There have been a couple of queries on the list about this subject and
I'd suggest that what we all took for granted in 1990 shouldn't be
happening in 2015.

I'd hope that Actian would step forward and present some strategies for
avoiding killing the user experience when long-running queries are being
run and not leave individual organisations to figure out individual
work-arounds for something that Actian should really have addressed.

I am out of touch with the latest versions of OR, but I don't believe
things have changed in this respect. If it has, it would be a great
reason for moving to a newer version of the product.

The world today is all about the user experience and that world is
getting ever more sophisticated and slick. We can't be happy with
leaving users twiddling their thumbs and staring at a dead screen, can we?

[Paul White]

It doesn’t matter what the technology - I think the problem is the same when dealing with long running operations. Your program needs to give an instant response back to the UI to say "thanks very much, request received, this will take just a few moments, check back later". The real processing needs to take place in the background on the same machine or a dedicated server.

We have some functions like periodic batch updates and reports managed on schedulers (written entirely in OpenROAD). The paradigm is - wait til the current job finishes before starting the next job. Heavy processing happens overnight. A dedicated job runs on a separate machine for deploying text and crystal reports.

I usually encourage my team to consider app servers, batch queue processors and load balancers. OpenROAD can do all of it.

I think of the behaviour of my favourite applications Excel, Outlook, Word, IE. When they get busy the entire desktop becomes sluggish or freezes up. The mouse cursor does not change shape when moving over application widgets. Cannot select other apps. Cannot alt-tab. Error, insufficient resources, application not responding, hmmmm.

Paul

&
Shift Seven Solutions
www.shift7solutions.com.au

[Paul A.]

On 13/03/2015 13:33, Paul White wrote:
> It doesn’t matter what the technology - I think the problem is the same when dealing with long running operations.

That's true, but OR is problematic because it's interactions with the
database a synchronous, so the UI really needs to be clever to take
account of that synchronicity and not run long-running queries directly.

Naturally there's latency and delay in all networked systems but having
a dead UI for more than a few seconds shouldn't be acceptable.

As you say there are workarounds, but it would be great for Actian to
lead with guidance on the issue.

In 2015 OR should have an established asynchronous query mechanism that
everyone should be using.

Nobody expects instant result delivery, but we should not kill the
interface because the server is busy.

[Paul White]

> .. it would be great for Actian to lead with guidance on the issue.

Yes, I agree. I wonder if it can be the subject of a code sprint.

We have a frame which checks occasionally on an ActiveX component which is busy retrieving document from web. The OpenROAD code continues running in parallel. Here is the code fragment.

ON USEREVENT 'loading' =
{
Li_Counter = Li_Counter + 1;
IF web1.busy = 0 THEN
doco1 = IHTMLDOCUMENT2(web1.document);
RETURN doco1.body.innertext;
ENDIF;
IF loading = '.' THEN
loading = '..';
ELSEIF loading = '..' THEN
loading = '...';
ELSEIF loading = '...' THEN
loading = '.';
ENDIF;
IF Li_Counter < Li_Timeout THEN
CurFrame.Senduserevent(eventname = 'loading', delay = .5);
ELSE
RETURN '';
ENDIF;
}


btw, I thought you'd be interested in a couple of items on my radar which have similar requirements to allow an interruption.

* We're supporting an application deployed on windows tough books mounted in trucks. OpenROAD fat client, Ingres Net, 3g mobile WAN. Often there is heavy duty traffic with bulk transaction updates. The truck passes under a bridge and, yup, the driver generally needs to ctr-alt-del kill and restart the app. At the server end, Ingres net finds out the connection has dropped several minutes later and eventually the transaction is rolled back. It's an problem for the rest of the LAN users waiting for locked resources to free up. The truck app is able to store local copies of transactions ready for update when the network comes back up. It can deal with a network fail part way through a batch update.

* At another site I see long running transactions for large invoices hit tables from Orders, Picklists, Invoices, Inventory/warehouse, Debtors, GL and Sales Summary. 20 or so tables in the transaction. These frequently deadlock and timeout other complex transactions. Frequency of problems increase when trying to scale to large orders or a large number of users. But it works fine for a small office deployment and with small orders of just a few lines.

* My favourite is a dashboard display in an application startup which takes around a minute to produce a summary grid of around 30 results from millions of rows. Every user who logs in the app runs the same SQLs and waits the same minute or so. They don’t question it because they have gone to get coffee.

[Paul A.]

On 13/03/2015 14:50, Paul White wrote:
>> .. it would be great for Actian to lead with guidance on the issue.
> Yes, I agree. I wonder if it can be the subject of a code sprint.
>
> We have a frame which checks occasionally on an ActiveX component which is busy retrieving document from web. The OpenROAD code continues running in parallel. Here is the code fragment.
>
> ON USEREVENT 'loading' =
> {
> Li_Counter = Li_Counter + 1;
> IF web1.busy = 0 THEN
> doco1 = IHTMLDOCUMENT2(web1.document);
> RETURN doco1.body.innertext;
> ENDIF;
> IF loading = '.' THEN
> loading = '..';
> ELSEIF loading = '..' THEN
> loading = '...';
> ELSEIF loading = '...' THEN
> loading = '.';
> ENDIF;
> IF Li_Counter < Li_Timeout THEN
> CurFrame.Senduserevent(eventname = 'loading', delay = .5);
> ELSE
> RETURN '';
> ENDIF;
> }
>
>
> btw, I thought you'd be interested in a couple of items on my radar which have similar requirements to allow an interruption.
>
> * We're supporting an application deployed on windows tough books mounted in trucks. OpenROAD fat client, Ingres Net, 3g mobile WAN. Often there is heavy duty traffic with bulk transaction updates. The truck passes under a bridge and, yup, the driver generally needs to ctr-alt-del kill and restart the app. At the server end, Ingres net finds out the connection has dropped several minutes later and eventually the transaction is rolled back. It's an problem for the rest of the LAN users waiting for locked resources to free up. The truck app is able to store local copies of transactions ready for update when the network comes back up. It can deal with a network fail part way through a batch update.

The truck app should store a queue of updates locally and the driver
should synchronise when the connection is reliable. The app itself
should not do the updates but queue them for another process to perform
- so all it ever does is insert changes to a queue table for another
process to action.

>
> * At another site I see long running transactions for large invoices hit tables from Orders, Picklists, Invoices, Inventory/warehouse, Debtors, GL and Sales Summary. 20 or so tables in the transaction. These frequently deadlock and timeout other complex transactions. Frequency of problems increase when trying to scale to large orders or a large number of users. But it works fine for a small office deployment and with small orders of just a few lines.

Yes, those long running transactions should be queued, not run by the UI
directly.

>
> * My favourite is a dashboard display in an application startup which takes around a minute to produce a summary grid of around 30 results from millions of rows. Every user who logs in the app runs the same SQLs and waits the same minute or so. They don’t question it because they have gone to get coffee.

I had this for an online display I made for a webapp. I built a result
cache and the system would keep the result of a query if no inserts or
updates were made to the tables involved, so any repeat queries already
had the results waiting and only the first query took the performance hit.

Paul

[Neil Warnock]

This might be of interest. It's essentially a mechanism for submitting server-side background jobs and being notified that they're finished.

http://community.actian.com/wiki/JIM_Home

Rgds

Neil.


Sent from Phone

> --
> You received this message because you are subscribed to the Google Groups "OpenROAD Users Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openroad-user...@googlegroups.com.
> To post to this group, send email to openroa...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openroad-users.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/5502FEDE.1050900%40ipauland.com.