Conference rocks::dec_edi

Hi,

I wondered when this would come in :-(

The IMO server is the one that maintains a pool of "Initial Object References"
that it doles out to requesting clients. 

When you have more than 20 active requests simultaneously you
get this error.

Do you have more than 20 outstanding requests? i.e. 20 active IMF servers?

If you don't, then read the note I wrote about OpenVMS V7. In one of
the replies is a small ObjectBroker re-configuration that can help.

Otherwise $application/broker stop server <imo-process-instance-uuid>

Mark

Hi Mark,

> When you have more than 20 active requests simultaneously you
> get this error.
> 
> Do you have more than 20 outstanding requests? i.e. 20 active IMF servers?

This is seen on a test and development system. It's only used by a few 
developers. It's unlikly there will be more then one or possible two
simultanious requests.

APPL/BROKER SHOW SERVER show one DECEDI_IMF_IMPL, one DECEDI_IMO_IMPL and
one DECEDI_IMT_IMPL server. A total of three servers.

> The IMO server is the one that maintains a pool of "Initial Object References"
> that it doles out to requesting clients.

Is there any way to see if "Initial Object References" are not returned to the
pool after beeing used?

> If you don't, then read the note I wrote about OpenVMS V7. In one of
> the replies is a small ObjectBroker re-configuration that can help.

I found this in 2978.6

> For ObjectBroker V2.7. This is required for a mixed TCP DECnet system and
> it appears to work around a serious problem that affects DEC/EDI:
....
> OBB> modify configuration "DECnet-Only Configuration"  /ACCEPT_AUTHR_WO_AUTHN

Sorry, but I was wrong about the Objectbroker version in .0 This system has 
OBB v2.6. Is the above command still of interest for OBB v2.6?

Thanks,
Sven-Olof

At the moment if the client experiences a communication failure after
it has started some operations, the IMO server is unaware that it
has gone away.

Another variant - does it fail after exactly 20 posts?


You could try that re-config on V2.6. 

M

> At the moment if the client experiences a communication failure after
> it has started some operations, the IMO server is unaware that it
> has gone away.

I'm getting worried now. This customer (Ericsson) is currently running V2.1C
and OBB V2.5B in their production environment. They have a quite large number
of clients, and this number is growing. I think they will have up to 50-100
clients connected to one EDI server. Some of them are connected via WAN 
connections were there from time to time are communication problems.

V2.1D and OBB V2.6 are planned to be installed on the production system in a 
few weeks. If "Initial Object References" are not returned to the pool by the
IMO server if a communication failure occurs I belive the IMO server will
run out of "Initial Object References" now and then.

Mark, can you comment this.

> Another variant - does it fail after exactly 20 posts?

I don't think so. But perhaps is it failing after 20 communication failures. 
While being logged on to the system I noticed one client has been connected
via a TCP/IP link most of the time.

UCX> SHOW DEVICE
....
  bg1946      STREAM    1161    2462                   osedt5.ericsson.se
....

Device BG1946 is owned by the DECEDI_IMF_IMPL server (when I have seen this,
this has been the only IMF server on the EDI server node).
$ SHOW DEVICE BG1946 /FULL shows that "Operations completed" only occasionly
increments.
Could this indicate a communication problem?
Or could be that the client is waiting for a document (TRADE FETCH/TIMEOUT=...)?


If the IMO server runs out of "Initial Object References" will any client
(local and remote) be able to post/fetch files? 
The customer has told me they have not seen any problem with remote clients 
to this system. I'm not 100% convinced this is true. I'll ask them to verify 
this.

Thanks,
Sven-Olof
                      

Hi Mark,

> OBB> modify configuration "DECnet-Only Configuration"  /ACCEPT_AUTHR_WO_AUTHN

This is allready set. OBB SHOW AGENT displays 
"Attributes: AuthrWOAuthn is ENABLED"

I belive this says /ACCEPT_AUTHR_WO_AUTHN has been set. 
On my test system I did set /NOaccept_authr_wo_authn. The OBB SHOW AGENT 
displayed "Attributes: AuthrWOAuthn is DISABLED" after that.


I read topic 2408 in OBJECTBROKER_DEVELOPMENT once again. You say that IMO
server does not know about servers that dies, and that this causes loss of
"Initial Object References" from the internal pool.
If a server had died would this mean I should see it on the EDI server node
with OBB SHOW SERVER as a server with status "died"?
Does it have to be on the EDI server node, or could servers have died on
EDI client nodes too?
I dont see any died OBB implementation servers on the EDI server node. See the
attached log.


This problem cause me problems. The customer want's to upgrade their production
system. But that's on hold until this problem is solved.
I might need to open a IPMT case on this.

Below is output from OBB SHOW AGENT and OBB SHOW SERVER when the problem is
seen. This is from the EDI server node.

Thanks,
Sven-Olof

EDITST>trade fetch anna dummy.file/link=dummy/typ=trans

%DECEDI-E-NOFREEOBJ, No free server available
%DECEDI-E-NOFREEOBJ, No free server available

EDITST>appl/broker sho agent

Agent on node: EDITST
  Version:      OBB V2.6-07
  Username:     system
  Time Started: Thu Apr 24 15:23:19 1997
  Pid:          00000EBF
  Log Filename: SYS$SPECIFIC:[OBB.SCRATCH.EDITST]OBB$AGENT.LOG;19
  Attributes:   AuthrWOAuthn is ENABLED
                Active transports are DECnet, TCPIP
                OrbV12 style Agent

EDITST>appl/broker sho server

Implementation Servers on node EDITST.

  Implementation Name                         Username      Status
  ------------------------------------------  ------------  ------
  DECEDI_IMF_IMPL                             decedi        Executing     
      Inst UUID:    7c3b7e871f40.0c.05.98.00.00.00.00.00    Pid: 00000E42
      Impl UUID:    68eb4b476f3b.0c.70.a9.00.00.00.00.00
      Registered at: Thu Apr 24 15:24:44 1997  

  Server has no attributes

  DECEDI_IMO_IMPL                             pvaseib       Executing     
      Inst UUID:    7c3b7cd86880.0c.39.04.00.00.00.00.00    Pid: 000041D3
      Impl UUID:    77b71d8d9182.0c.d0.a8.00.00.00.00.00
      Registered at: Thu Apr 24 15:29:22 1997  

  Server has no attributes

  DECEDI_IMT_IMPL                             edtoguz       Executing     
      Inst UUID:    7c3c296bd5df.0c.39.04.00.00.00.00.00    Pid: 00001CBC
      Impl UUID:    68eeba773e38.0c.70.a9.00.00.00.00.00
      Registered at: Thu Apr 24 18:35:59 1997  

  Server has no attributes

%OBB-I-CMD_NUMMSRVSFND, 3 servers found. 

Hi,

The server dieing is just one possible circumstance.

The other is client failure. Are the clients seeing any communication
errors?

M

Hi,

> The other is client failure. Are the clients seeing any communication
> errors?

I don't know. The problem here is that there are several clients in diffrent
countries. It's difficult to monitor all of them. It's not easy to tell all 
users either that they must tell us about communication problems.

I would guess that there are communications problems between the server and
the clients. I have seen problems with their network before when I have been 
logged on to their system. This has not caused any problems with EDI V2.1C 
and OBB V2.5B wich is their current production environment.
If DEC/EDI can't handle communication problems properly it's a show stopper
for upgrading the production environment.

I have asked the customer to verify if remote clients also see this problem.
No reports of problems has been received from remote clients, but I guess they
see problems too (perhaps the users on remote systems don't reports problems
if they belive it's the network...). Problem frequency is 1-2 times/week.

Mark, do you have any idea on how to find this problem?
What about a special IMO debug image that log information when giving a object
reference to a client, and return of it?


Sven-Olof

    Hi,
    
    In case anyone wonders......
    The problem has not been seen for a while. I don't know why.
    Nothing has been fixed.
    
    This is bad since the customer is afraid the the problem will come
    back (and so am I) and dare not to upgrade their production system.
    Something must be causing the problem. I wish I did not what....
    
    /Sven-Olof
              

We are doing a bit of re-design of the IMO server.

Basically it works well as long as there no communication problems.
We will make it more so shortly.

Mark