When Forté 3.0.M.0?
You can do a forum search on 3.0. It has been discussed countless times. MMS is included, but not for 1st gen iphones.
3.0 is due out this summer.
http://www.apple.com/iphone/preview-iphone-os/
http://events.apple.com.edgesuite.net/0903lajkszg/event/index.html
Similar Messages
-
RE: (forte-users) When Fort 3.0.M.0?
Hi Stella
How about release 4.0???
-----Original Message-----
From: Stephen Szalla [mailto:sszallaforte.com]
Sent: Tuesday, January 11, 2000 6:02 AM
To: Daniel; Dave Leach; Lista Fort (II)
Cc: Manuel Fernndez; Federico Muoz; Jose Ignacio
Subject: Re: (forte-users) When Fort 3.0.M.0?
Daniel/Dave and whoever else is interested in 3.0.M.0:
Note that 3.0.M.0 is a "pull" release - you have to request it to get it.
Stephen Szalla
At 09:09 11/01/00 +0100, Daniel wrote:
Hi Forté users,
Is there any body using Forté 3.0.M.0 with AIX 4.3.
Does any one know anything about this release and when is it going to be
distributed.
Daniel González de Lucas.
EAM Sistemas Informáticos S.L.
Valladolid (Spain)
Tel. +34 983 35 29 22
Fax. +34 983 35 21 15
e-mail danieleam.es <mailto:danieleam.es>
Stephen Szalla
Senior Technical Specialist
Forte Software Australia - A subsidiary of Sun Microsystems
Voice: +61 3 9699 7754
Fax: +61 3 9699 7781
Mobile: +61 419 392 867
mailto:sszallaforte.com <<a
href=
"mailto:sszallaforte.com">mailto:sszallaforte.com</a>>
http://www.forte.com <<a
href="http://www.forte.com/">http://www.forte.com/</a>>Hi Stella
How about release 4.0???
-----Original Message-----
From: Stephen Szalla [mailto:sszallaforte.com]
Sent: Tuesday, January 11, 2000 6:02 AM
To: Daniel; Dave Leach; Lista Fort (II)
Cc: Manuel Fernndez; Federico Muoz; Jose Ignacio
Subject: Re: (forte-users) When Fort 3.0.M.0?
Daniel/Dave and whoever else is interested in 3.0.M.0:
Note that 3.0.M.0 is a "pull" release - you have to request it to get it.
Stephen Szalla
At 09:09 11/01/00 +0100, Daniel wrote:
Hi Forté users,
Is there any body using Forté 3.0.M.0 with AIX 4.3.
Does any one know anything about this release and when is it going to be
distributed.
Daniel González de Lucas.
EAM Sistemas Informáticos S.L.
Valladolid (Spain)
Tel. +34 983 35 29 22
Fax. +34 983 35 21 15
e-mail danieleam.es <mailto:danieleam.es>
Stephen Szalla
Senior Technical Specialist
Forte Software Australia - A subsidiary of Sun Microsystems
Voice: +61 3 9699 7754
Fax: +61 3 9699 7781
Mobile: +61 419 392 867
mailto:sszallaforte.com <<a
href=
"mailto:sszallaforte.com">mailto:sszallaforte.com</a>>
http://www.forte.com <<a
href="http://www.forte.com/">http://www.forte.com/</a>> -
RE: (forte-users) 3J= 3M new to me error
Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.comHi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com -
Bus error in the Forte executable
Hi,
We have an environment with forte' (ver. 3.0.G.2) running
on AIX 4.1 (The name of central server is cld_app1 and the nodemgr start
with the name cld_TDR). In our environment we are using two differnet
repository. In rep1 we have a very simple project (called 'aaa') that
use one small class with two methods. One method print the date & time.
The second method communicate with a serviceobject that use MQSeries to
put/get some messages in the queues.
The project work correctly in test run and in distribuite mode.
If we export the same project (aaa) and we import in other repository
(rep2 in the same environment) the project doesn't work. Infact,
during test run forte' return the following:
Begin Stack Backtrace
=========================================================
=
Trace caused by a bus error in the Forte executable:
ftexec Version 3.0.G.2
IBM RS6000/Aix 4.1
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-1998, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1995-1998, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United
States.
Fri Mar 13 16:07:45 1998
Fault at 25-Mar-1999 10:42:53, pid '2292', node 'cld_app1':
0xd0b8886c = d0b8886c()
0xd0b88ae4 = d0b88ae4()
qqos_StkTrc: Cannot print stack trace.
Recursive stack trace detected. Exiting.
If we try to run in partitioning mode, the same error appears when
forte' "loading partition into server" with the following adding
message:
Unable to start the partition aaa_cl0_Part1 on any of nodes to wich
been assigned. See the remainder of the error stack for more
information.
In the "more" informations we have the following:
SYSTEM ERROR: Unable to start the partition aaa_cl0_Part1 on any of the
nodes to which it has been assigned. See the remainder of the error
stack for more
information.
Class: qqsp_ResourceException
Error #: [1602, 593]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 5
Last TOOL statement: method overview.StartApplication
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Unable to start partition aaa_cl0_Part1 on node cld_TDR.
Class: qqsp_ErrorDescriptor
Error #: [1602, 592]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 3
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Lost contact with remote server while trying to load
partition
aaa_cl0_Part1. Check server log file for more information about the
specific
problem.
Class: qqsp_ResourceException
Error #: [1301, 102]
Detected at: qqem_IPartitionAgent::Startup at 5
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: The connection to the partner was terminated by the
Communication
Manager for the reasons below.
Class: qqsp_DistAccessException
Detected at: qqdo_PartitionMgr::StopLocation at 1
Error Time: Thu Mar 25 09:22:20
Distributed method called: qqrt_ForteExecAgentProxy.LoadPartition!6
(object name Unnamed) from partition "Forte_Executor",
(partitionId =
546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158.19]) in application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Network partner closed connection. This usually means the
process at the other end of the wire failed. Please go look there and
find
out why.
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 2
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Error parameters for Set:0 Msg:0:
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 1
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
Thanks in advance
Luz Marina e Massimiliano
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Hi,
We have an environment with forte' (ver. 3.0.G.2) running
on AIX 4.1 (The name of central server is cld_app1 and the nodemgr start
with the name cld_TDR). In our environment we are using two differnet
repository. In rep1 we have a very simple project (called 'aaa') that
use one small class with two methods. One method print the date & time.
The second method communicate with a serviceobject that use MQSeries to
put/get some messages in the queues.
The project work correctly in test run and in distribuite mode.
If we export the same project (aaa) and we import in other repository
(rep2 in the same environment) the project doesn't work. Infact,
during test run forte' return the following:
Begin Stack Backtrace
=========================================================
=
Trace caused by a bus error in the Forte executable:
ftexec Version 3.0.G.2
IBM RS6000/Aix 4.1
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-1998, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1995-1998, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United
States.
Fri Mar 13 16:07:45 1998
Fault at 25-Mar-1999 10:42:53, pid '2292', node 'cld_app1':
0xd0b8886c = d0b8886c()
0xd0b88ae4 = d0b88ae4()
qqos_StkTrc: Cannot print stack trace.
Recursive stack trace detected. Exiting.
If we try to run in partitioning mode, the same error appears when
forte' "loading partition into server" with the following adding
message:
Unable to start the partition aaa_cl0_Part1 on any of nodes to wich
been assigned. See the remainder of the error stack for more
information.
In the "more" informations we have the following:
SYSTEM ERROR: Unable to start the partition aaa_cl0_Part1 on any of the
nodes to which it has been assigned. See the remainder of the error
stack for more
information.
Class: qqsp_ResourceException
Error #: [1602, 593]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 5
Last TOOL statement: method overview.StartApplication
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Unable to start partition aaa_cl0_Part1 on node cld_TDR.
Class: qqsp_ErrorDescriptor
Error #: [1602, 592]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 3
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Lost contact with remote server while trying to load
partition
aaa_cl0_Part1. Check server log file for more information about the
specific
problem.
Class: qqsp_ResourceException
Error #: [1301, 102]
Detected at: qqem_IPartitionAgent::Startup at 5
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: The connection to the partner was terminated by the
Communication
Manager for the reasons below.
Class: qqsp_DistAccessException
Detected at: qqdo_PartitionMgr::StopLocation at 1
Error Time: Thu Mar 25 09:22:20
Distributed method called: qqrt_ForteExecAgentProxy.LoadPartition!6
(object name Unnamed) from partition "Forte_Executor",
(partitionId =
546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158.19]) in application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Network partner closed connection. This usually means the
process at the other end of the wire failed. Please go look there and
find
out why.
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 2
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Error parameters for Set:0 Msg:0:
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 1
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
Thanks in advance
Luz Marina e Massimiliano
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
forte-users-digest Tuesday, 8 October 1996 Volume 01 : Number 089
From: Alexander Ananiev <[email protected]>
Date: Tue, 08 Oct 1996 16:36:14 -0500
Subject: "Single DBSession" approach
The standard Forte approach for the database access assumes
that one DBSession handles requests from several users
(clients), so the database connection is not associated with
the particular user. This significantly impacts the
architecture of the Forte application. Some of the problems
caused by this approach are:
1) An application-level security system should be developed
instead of using the DBMS security system. Suffice it to say
that application-level security system cannot provide the
protection from back-door access to the database.
2) The application cannot utilize the DBMS locking mechanism
for the case when the record is retrieved to the client for
editing purposes ("long" transaction).
It means that SecurityManager and LockManager should be
developed to resolve these problems. This does not seem to be
very good solution because these objects are intended to repeat
the functionality of the DBMS. And these parts of the
application may become pretty complicated. For example, my
project's experience shows that the development of the lock
manager is not a trivial task and most likely this lock manager
will be worse than the DBMS locking mechanism in terms of
reliability and performance just because it acts as an outside
program to the database. Besides, this approach could cause
serious problems if the database can be updated by non-Forte
applications (e.g., by some legacy system or batch process).
"One DBSession per several users" approach makes sense if each
user connection to the database is implemented as one
server process.(Another good argument in favor of single
DBsession is a heterogeneous environment where there is no
stable connection to one database, but here I'm talking about a
"regular" application that uses only one DBMS.) Since most of
the time this process is idle, then, of course, decreasing the
number of processes leads to better server utilization and
performance. But by its sense, database connection is just the
current transaction ID (with the user id, of course). So the
connection could be just a number that should be passed to the
DBMS along with each request and then DBMS can create a thread
to handle the request or forward it to the next available
process if it does not support multithreading.
DBMS vendors realize this and some of them already implemented
this approach (I know that Oracle and Informix did that and
Sybase was mentioned in the recent "one-threaded DBSession"
discussion). And one-threaded DBSession that lives on the
server doesn't fit well to that. The better approach would be
to make DBSession the attribute of the TransactionHandle
object, so the current connection will always be passed from
the client to the service and this service can work through
this connection.
So, my point is that the application should let DBMS do its
work and use as much of the functionality of the DBMS as
possible and the "single DBsession" approach doesn't help it to
do that.
I would be glad to hear any other opinion on this topic. I
think that the "DBsession" problem is extremely important for
any multi-tier application (for example, all Web applications
are facing this problem). I'm also interested in how people
are dealing with this problem on other projects, for example if
there are some projects where the alternative approach (one
DBSession per each user) was implemented and what problems were
encountered during that.
Alexander Ananyev
Price Waterhouse
End of forte-users-digest V1 #89
One of the first issues that needs to be addressed is that passing
DBSessions from partition to partition is a huge performance hit. When
Forte executes a SQL SELECT or FETCH statement on a DBSession that exists
outside the current partition (DBSessions are "anchored" objects that are
accessed via proxies.) Forte fetches the result set into the partition
containing the DBSession and then passes proxies or creates copies into
the partition where the SQL code is located. These are some of the
largest performance hits you can take in Forte.forte-users-digest Tuesday, 8 October 1996 Volume 01 : Number 089
From: Alexander Ananiev <[email protected]>
Date: Tue, 08 Oct 1996 16:36:14 -0500
Subject: "Single DBSession" approach
The standard Forte approach for the database access assumes
that one DBSession handles requests from several users
(clients), so the database connection is not associated with
the particular user. This significantly impacts the
architecture of the Forte application. Some of the problems
caused by this approach are:
1) An application-level security system should be developed
instead of using the DBMS security system. Suffice it to say
that application-level security system cannot provide the
protection from back-door access to the database.
2) The application cannot utilize the DBMS locking mechanism
for the case when the record is retrieved to the client for
editing purposes ("long" transaction).
It means that SecurityManager and LockManager should be
developed to resolve these problems. This does not seem to be
very good solution because these objects are intended to repeat
the functionality of the DBMS. And these parts of the
application may become pretty complicated. For example, my
project's experience shows that the development of the lock
manager is not a trivial task and most likely this lock manager
will be worse than the DBMS locking mechanism in terms of
reliability and performance just because it acts as an outside
program to the database. Besides, this approach could cause
serious problems if the database can be updated by non-Forte
applications (e.g., by some legacy system or batch process).
"One DBSession per several users" approach makes sense if each
user connection to the database is implemented as one
server process.(Another good argument in favor of single
DBsession is a heterogeneous environment where there is no
stable connection to one database, but here I'm talking about a
"regular" application that uses only one DBMS.) Since most of
the time this process is idle, then, of course, decreasing the
number of processes leads to better server utilization and
performance. But by its sense, database connection is just the
current transaction ID (with the user id, of course). So the
connection could be just a number that should be passed to the
DBMS along with each request and then DBMS can create a thread
to handle the request or forward it to the next available
process if it does not support multithreading.
DBMS vendors realize this and some of them already implemented
this approach (I know that Oracle and Informix did that and
Sybase was mentioned in the recent "one-threaded DBSession"
discussion). And one-threaded DBSession that lives on the
server doesn't fit well to that. The better approach would be
to make DBSession the attribute of the TransactionHandle
object, so the current connection will always be passed from
the client to the service and this service can work through
this connection.
So, my point is that the application should let DBMS do its
work and use as much of the functionality of the DBMS as
possible and the "single DBsession" approach doesn't help it to
do that.
I would be glad to hear any other opinion on this topic. I
think that the "DBsession" problem is extremely important for
any multi-tier application (for example, all Web applications
are facing this problem). I'm also interested in how people
are dealing with this problem on other projects, for example if
there are some projects where the alternative approach (one
DBSession per each user) was implemented and what problems were
encountered during that.
Alexander Ananyev
Price Waterhouse
End of forte-users-digest V1 #89
One of the first issues that needs to be addressed is that passing
DBSessions from partition to partition is a huge performance hit. When
Forte executes a SQL SELECT or FETCH statement on a DBSession that exists
outside the current partition (DBSessions are "anchored" objects that are
accessed via proxies.) Forte fetches the result set into the partition
containing the DBSession and then passes proxies or creates copies into
the partition where the SQL code is located. These are some of the
largest performance hits you can take in Forte. -
Forte IIOP / Corba / Java other questions...
I've a problem with Forte (3.0.E.0) generating IDL that is causing
Visigenic Visibroker 2.5 (for Java) compile errors...
It has something to do with the order(ing) of interfaces declaration
and referencing these interfaces within the generated IDL file ...
To fix thix, I've to hand edit the IDL file and declare the interfaces
before they are referenced in some other Interface declaration...Since
we have a lot of classes, it can take time to do this...
Is this a known bug ? undocumented behavior ? is there any way to
workaround this ? I would assume that Interface declaration/referencing
should be done in proper order (When forte generates IDL), but it is
not.
Thanks for any help,
--francois
Francois Orsini
Evolve Inc - 615 Battery Street - San Francisco, CA 94111
(415) 439-4076 - Email: [email protected]I've a problem with Forte (3.0.E.0) generating IDL that is causing
Visigenic Visibroker 2.5 (for Java) compile errors...
It has something to do with the order(ing) of interfaces declaration
and referencing these interfaces within the generated IDL file ...
To fix thix, I've to hand edit the IDL file and declare the interfaces
before they are referenced in some other Interface declaration...Since
we have a lot of classes, it can take time to do this...
Is this a known bug ? undocumented behavior ? is there any way to
workaround this ? I would assume that Interface declaration/referencing
should be done in proper order (When forte generates IDL), but it is
not.
Thanks for any help,
--francois
Francois Orsini
Evolve Inc - 615 Battery Street - San Francisco, CA 94111
(415) 439-4076 - Email: [email protected] -
Hi Everybody,
Does any one worked on a C++ application communicating with a Forte Service
Object via Visibroker. Problem we are facing is we could't able to call a
Service Object Method which is returning a Array of Objects. Forte
generating the IDL for the function but when we tried to access the function
from the C++ client causing CORBA::UNKOWN exception.
thanks in advance..
[email protected]
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Hi, Srinivas
I do have "a C++ application communicating with a Forte Service Object via
Visibroker", and also my remote method of the service object is returning an
Array of Object (to be exact, a subclass of Object). It is hard to figure out
what happened just from the information you provided here. If you could provide
more information, it might be helpful.
CORBA::UNKOWN exception: The explanation is The ORB could not determine the
thrown exception. The server throws something other than a correct exception
such as Windows runtime exception.
By default, when Forte generates an IDL method, it raises an exception either
GenericException or UserException. You can subclass GenericException or
UserException to add custom exception classes.
Shilong Yin
US West in Denver
Srinivas Delu wrote:
Hi Everybody,
Does any one worked on a C++ application communicating with a Forte Service
Object via Visibroker. Problem we are facing is we could't able to call a
Service Object Method which is returning a Array of Objects. Forte
generating the IDL for the function but when we tried to access the function
from the C++ client causing CORBA::UNKOWN exception.
thanks in advance..
[email protected]
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Re: Actuate in Forte Application
This is just a guess, but it looks to me like perhaps
NT is not recognizing "cl" as a command. What happens
when you type "cl" on a command line?
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Have you run the 'vcvars32.bat before, or registered
any required variable in environmental memory ?
(devstudio/vc/bin/vcvars32.bat if I remember well :-) )
bye
j-p
-----Message d'origine-----
De: Kien Chung Chin [SMTP:[email protected]]
Date: lundi 3 mai 1999 09:16
A: Forte Users
Objet: Actuate in Forte Application
Hi, guys,
Currently, I am testing on Actuate called from Forte Application. I
downloaded the example from Forte support web site. I tried and followed
the instruction that was given, but I couldn't make it work.
The problem is Forte couldn't produce the DLL file; there has MS Visual
C++ 5.0 installed.
I did;
- actlayer.obj has been produced (with reqbasic.h)
- before actwrap.pex import into Forte external library (reqst32.dll)
change to relevent directory; and also external object file
(actlayer.obj).
- when Forte compilation library (DLL) cannot be produce. (include
directories for c++, Actuate and Forte were set into system variable -
path). It gave the following error:
Forte_cl0: Fetched SubAgents
Forte_cl0: Generating code for library ActWrap.
Forte_cl0: Completed code generation for ActWrap.
Forte_cl0: Attempting to obtain compile sessions for needed
architectures.
Forte_cl0: Beginning compilation for PC NT.
Forte_cl0: Compilation of actwrap on PC NT completed. Here are the
results:
BEGIN FILE
Working directory is c:\forte\tmp\cg2\pc_nt\actwrap
Processing BOM file: actwrap.bom
The name specified is not recognized as an
internal or external command, operable program or batch file.
cl /W3 /Gf /GX /MD /c /Ob1 /vmg /DSTRICT /DWIN32 /D__WIN32__
/DLIBOO_DLL /DWIN32_LEAN_AND_MEAN
/Ic:\forte\install\inc\cmn /Ic:\forte\install\inc\os
/Ic:\forte\install\inc\ds
/Ic:\forte\install\inc\handles /Ic:\forte /Foactwrap.obj /Tp actwrap.cc
Error during compilation, aborting.
END FILE
Forte_cl0:
Forte_cl0: Completed compilation for PC NT.
I continue to import the interface part, when run interface Forte gave
'actwrap.dll' not found in 'c:\forte\userapp\actwrap\cl0' directory.
Is there anyone try on that example? I hope I can get help from you, and
your little suggestion is a big help for me, I am very much appreciated.
Regards,
William
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Forte v3 - date for commercial release
Greetings All
Does anyone know when Forte 3 will be released and, more particularly,
when the Forte training materials will have been upgraded to the new
version ?
I'm taking both Forte application development classes in the UK in a
month's time, and am hoping they will cover release 3.
Kind regards, Robin.
Robin M. Roos <[email protected]>
Computer Consultant, Milton Keynes, UK.
Progress (see you in Boston?), Actuate, and Forte in due course...At 10:36 PM 5/20/97 +0100, Robin M. Roos wrote:
Does anyone know when Forte 3 will be released and, more particularly,
when the Forte training materials will have been upgraded to the new
version ?R3 beta is available now to pretty much anyone with a serious need. R3 is
projected for "production" release in August which means that any new users
will get it then as will any existing users who ask for it. About three
months later will come the maintenance release mailed without request to
those on maintenance.
R3 training is available now, although I believe it is a 3 day
"differences" class, i.e., go ahead and do your basic training and then
take the differences class to get ready for R3.
=========================================================================
Thomas Mercer Hursh, Ph.D email: [email protected]
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950 -
Hi Everybody,
we are connecting to Forte conductor from a VC++ client via Visibroker. we
could able to open a session with the conductor but when we try to access
getActivitiesList it is returning null eventhough there are activities for
the user.
sample code:
CMyWFClient *theClient = new CMyWFClient();
const char* mypasswd = (const char*)((CCRMTSApp*)AfxGetApp())->passwd;
theClient->OpenSession((const char*)m_USER_ID,(const
char*)((CCRMTSApp*)AfxGetApp())->passwd,MyAssignments);
WFClientLibrary::sequence_WFActivity_ptr CurUserActivities;
do
CurUserActivities =
theClient->theSession->GetActivityList(WFCorbaApi::CorbaWFSession.AL_EVENTS_OFF|WFCorbaApi::CorbaWFSession.SAVE_UPDATES_ON);
if(!CurUserActivities->length())
_sleep(1000);
}while(!CurUserActivities->length());
Are there any possibilities of going wrong in the ORB-Conductor
communication.
thanks in advance
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Hi, Srinivas
I do have "a C++ application communicating with a Forte Service Object via
Visibroker", and also my remote method of the service object is returning an
Array of Object (to be exact, a subclass of Object). It is hard to figure out
what happened just from the information you provided here. If you could provide
more information, it might be helpful.
CORBA::UNKOWN exception: The explanation is The ORB could not determine the
thrown exception. The server throws something other than a correct exception
such as Windows runtime exception.
By default, when Forte generates an IDL method, it raises an exception either
GenericException or UserException. You can subclass GenericException or
UserException to add custom exception classes.
Shilong Yin
US West in Denver
Srinivas Delu wrote:
Hi Everybody,
Does any one worked on a C++ application communicating with a Forte Service
Object via Visibroker. Problem we are facing is we could't able to call a
Service Object Method which is returning a Array of Objects. Forte
generating the IDL for the function but when we tried to access the function
from the C++ client causing CORBA::UNKOWN exception.
thanks in advance..
[email protected]
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Loadbalancing a service object
Hello,
I tried to loadbalance a service object that has both methods and
attributes. The first copy of the service object works fine. However, all
the attributes of the second copy of the service object are nil when a
client try to use this copy. How can I make those two copies exactly the
same?
I am new to Forte. Any input will be greatly appreciated.
Menghua Xiao
Regional Transportation District,
Denver, Colorado, USAMenghua Xiao wrote:
I tried to loadbalance a service object that has both methods and
attributes. The first copy of the service object works fine. However, all
the attributes of the second copy of the service object are nil when a
client try to use this copy. How can I make those two copies exactly the
same?Ummmmm ...
How are you initializing these attributes? In your Init method? Do you need
to refer to any other SOs to do it? Forte does not guarantee the order in
which service objects are initialized. Referring to other SOs in the Init
method may not work, or it may work well for a long time and then suddenly
break when Forte decides to initialize things in a different order in
response to an upgrade, or to some random change in the application, or for
no known reason. If you're replicating, things could conceivably get even
more complex, with different replicates being initialized at different
times. And if one if the Init methods fails, Forte can't create the service
object, and your entire application fails to start.
Furthermore, Forte will tell you that attributes on a service object are a
bad idea. It's possible that they tell you this because there are bugs
around it that they're ashamed to tell you about (have you checked Forte's
web page?). Even if there are no bugs, there are a BUNCH of traps you can
fall into if you do this. The only time I consider it safe to have
attributes on a replicated SO is if those attributes can be reliably
maintained on that SO. This restricts it to:
* Database connection objects, and other such things that don't need to be
in synch.
* Static data that NEVER, NEVER changes.
The reason for these severe restrictions are that there are no reliable
ways to keep the two SOs in synch.
All that said, how can you get away with it? My religion says the best way
is to turn your attributes into virtual attributes. The quick and dirty way
to do this is:
1. Rename the attribute from AttrName to PrivateAttrName, and MAKE IT
PRIVATE.
2. Write a GetAttrName method that returns the attribute. This method
should check to see if the attribute is NIL, and if so load it. It ends
with "Return PrivateAttrName;".
3. Re-create AttrName as a virtual attribute, with "GetAttrName ()" (no
semicolon) as its get expression.
This approach gets the initialization of the attribute out of the Init
method, and instead forces initialization on the first reference. Hopefully
this solves all the problems. If it does not solve them, you ought at least
to get a useful error message out of your service object this way. I hope.
Good luck,
Tom Wyant -
To all -
This is an FYI. We just moved from d2 to e2 at the urging of the support
center as we had experienced several corruptions of workspaces with d2
during updates. E2 has solved this nicely but we have just suffered from
a new problem.
We are using window inheritance including inheritance of things like
standard buttons and scroll bars. Yesterday, I made a change to one
superclass to rearrange the order of buttons in a grid. After I did this,
16 of 18 subclass windows were not longer accessible. We could not
compile them, export them, or every go into the window workshop! We
kept getting FTEXEC errors in a qqds.dll module. And of course this was
during testing of the application prior to deployment for a trade
show on Wednesday! Panic city...
The support center explained the likely problem as one of duplicate
tags. Apparently, we had in d2 created window widgets (specifically
grid fields) without giving them names. We had done this variably
on the superclass and subclass. When Forte e2 tried to merge the
super and subclasses, it found a conflict between the tags (apparently
these are system assigned numbers). It is supposed to just give a
warning about these problems but in this case, it completely crashed.
The solution was not completely terrible but took several hours. We
first fixed the superclass to make sure all grids were names. Then
we dragged/dropped the subclass windows into a new project. There we
could access them and give all grids names. Then we deleted the originals
and dragged/dropped the copies back in. Voila! Fixed after about 3
hours and a bit of sweating.
The moral of this story is to name all widgets including grids and to
tread lightly when changing widgets in superclass windows.
Jerry Fatcheric
Relational Options, Inc.
Florham Park, New Jersey
201-301-0200
201-301-00377 (FAX)
[email protected]We've been talking about this issue for a while now. Take a look at this post:
Temperance Harkins, "are you an Audible.com user?" #16, 11:20am Oct 26, 2005 CDT -
When Forte' is processing, the mouse pointer becomes an hourglass. However,
if the mouse is moved so that it is no longer over a "Forte'" window, the
hourglass changes back to an arrow (even though the processing is not yet
complete). Does anyone know how to make the mouse pointer remain an hourglass
while Forte' is processing, regardless of where you move your mouse? This
issue arises both in designing applications using Forte' and in using
applications created in Forte'. Is the solution the same in both scenarios?
Thanks!
GlenHello Vikas,
Sorry but your link http://apex.oracle.com/pls/otn/f?p=24317:117 does'nt work !!
I receive this error:
ORA-01722: invalid number
Erreur ERR-1003 Erreur lors de l'exécution d'une interrogation de calcul
Message was edited by:
Fernand -
Nodemgr process consuming memory
All,
We have a problem we've been experiencing for some time where the nodemgr
process starts consuming over 2gig of memory - at the OS level and locking up
our server at times. This happened on Solaris 2.6
with various older versions of Forte and we were told that upgrading to
version 3J1 would resolve it.
Unfortunately, it hasn't resolved the problem. It has happened again to an
application written in 3J1 on Unix Sun Solaris 2.6.
Forte is saying that no other company has experienced this problem with 3J1 on
Solaris 2.6. Please let me know if you have so I can relate this to Forte.
Thanks,
Peggy Adrian
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>On Fri, 5 Mar 1999, Peggy Lynn Adrian wrote:
Unfortunately, it hasn't resolved the problem. It has happened again to an
application written in 3J1 on Unix Sun Solaris 2.6.We have experienced it too, with the previous releases man times.
With J1 I don't remember it happened ...
But, my 2cents : to save the OS , set a user limit of virtual memory
usage:
I use bash, I set it with ulimit -v 256000 to 256MB.
Interestingly when Forte crashes, it uses almost that amount of memory,
and one processor (we have a dual machine). And not more (that's why the
system can't kill it :) )
By the way, we have experienced some ftexec failures (memory and CPU
consumption) with J1 too, but since they were not reproducable, we did not
reported them. My tip : there may be a problem around the garbage
collection routine (that is just a tip from the outside). It seem to
happen when something made lots of objects, and consumed lots of memory.
GA'BRIEL, A'kos ([email protected]) FAX: (+36-1) 4312-977
UNIX & Internet consultant Phone: (+36-1) 4312-979
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Is there anything we need to look out for when running Forte 3.0.N.1 and iDS5.0 SP1 on WindowsXP?
We are in the process of migrating to Windows XP and during the transition period from 95 to XP we will need to run the uncertified for XP products Forte 3.0.N.1 client runtime and the iDS5.0 SP1 admin console on XP for a time.
We were just wondering if there were any gotchas or problems we need to look out for?Hi Kelsey,
Forte 3.0.N.1 is not certified to run on Windows XP. UDS 5.0.1 is the only certified ti run on Windows XP but just as client and is not certified to be a Server.
Anyway, let me know what your problems were when running Forte on Windows XP.
Cheers!!!
Maybe you are looking for
-
BPM Process chain takes long time to process
We have BI7, Netweaver 2004s on Oracle and SUN Solaris There is a process chain (BPM) which pulls data from the CRM system into BW. The scheduled time to run this chain is 0034 hrs. This chain should ideally complete before / around 0830 Hrs. <b>Now
-
Wondering how to generate and insert just the "f" for Facebook and "t" for Twitter into my iweb site. I am not looking for the profile badges but just the letters as seen on many sites. When someone clicks on the "f" or "t" they would be directed to
-
How do i download quicktime to my ipod?
how do i download quicktime to my ipod?
-
Improving performance while adding groups
Hello, I've been monitoring my crystal reports from a week or so and the report performance is going for a toss. I would like to narrate this in little detail. I have created 3 groups to select dynamic parameters and each group has a formula for itse
-
Hi All, Some of the users using my appliation is getting the below error. Short text The ASSERT condition was violated. What happened? In the running application program, the ASSERT statement recognized a situation that should not have occurred. The