[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::objectbroker

Title:ObjectBroker - BEA Systems' CORBA
Notice:See note 3 for kits; note 5 for training; note 1134 for releases
Moderator:TLE::PARODId
Created:Tue Jul 11 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1413
Total number of notes:6391

1382.0. "ivbuflen on large packet" by CSC32::R_GOLLEHON () Thu Mar 13 1997 22:40

    Just what you wanted...another DEC/EDI crosspost.
    
            <<< ROCKS::DISK$APPL01:[NOTES$LIBRARY]DEC_EDI.NOTE;1 >>>
                                  -< DEC/EDI >-
================================================================================
Note 3056.0               Obb transport error, ivbuflen               No replies
CSC32::R_GOLLEHON                                    54 lines  14-MAR-1997 00:37
--------------------------------------------------------------------------------
    Hello,
    
    Got another annoying OBB question...I'm getting the following message
    reported on a 2.1D server in the trace file for the decedi$imf process. 
    OBB version is v2.7.
    
    *** Request Sent: Synchronous Invoke.
    *** Method: 68eb4b476f40.0c.70.a9.00.00.00.00.00.
    ***    MethodServerClass: 68eb4b476f3f.0c.70.a9.00.00.00.00.00
    *** Request Sent: Synchronous Invoke.
    *** Method: 68eb4b476f40.0c.70.a9.00.00.00.00.00.
    ***    MethodServerClass: 68eb4b476f3f.0c.70.a9.00.00.00.00.00
    *** Request Sent: Synchronous Invoke.
    *** Method: 68eb4b476f40.0c.70.a9.00.00.00.00.00.
    ***    MethodServerClass: 68eb4b476f3f.0c.70.a9.00.00.00.00.00
    ***    Marshalled Buffer: 66332
    ***    Marshalled Buffer: 66332
    ***    Marshalled Buffer: 66332
    ***    Allocated Buffer : 67611
    ***    Allocated Buffer : 67611
    ***    Allocated Buffer : 67611
    --- SAR: Sending message on socket 9
    --- SAR: Sending message on socket 9
    --- SAR: Sending message on socket 9
    --- Sending on socket 9
    --- Sending on socket 9
    --- Sending on socket 9
    --- Total data length is 66332
    --- Total data length is 66332
    --- Total data length is 66332
    --- Sending data on socket - len is 65535
    --- Sending data on socket - len is 65535
    --- Sending data on socket - len is 65535
    --- Error sending data - error value is 65535
    --- Error sending data - error value is 65535
    --- Error sending data - error value is 65535
    ***    Transport Status: %OBB-E-INV_TRANSERR, Transport error
    `$TransportError$
    ***    Transport Status: %OBB-E-INV_TRANSERR, Transport error
    `$TransportError$
    ***    Transport Status: %OBB-E-INV_TRANSERR, Transport error
    `$TransportError$
    
    The error is an SYSTEM-F-IVBUFLEN, invalid buffer length.  I would
    assume that the error is due to the data size.   My question is the
    65535 a maximum datagram size for tcp/ip?  Can this value be increased
    or decreased?  Can OBB be made to send smaller packets?
    
    The customer is using TCPware from Process Software (officially
    supported for use with OBB)...anyone have any experience with this?
    
    Thanks,
    
    -Robert
    
    
T.RTitleUserPersonal
Name
DateLines
1382.1REQUE::BOWERPeter Bower, ObjectBrokerSat Mar 15 1997 10:5113
    Is there a reason why everything is repeated 3 times ?
    
    Where did the customer see the IVBUFLEN error ? I would have
    expected to see it after the INV_TRANSERR error message.
    
    OBB is making a call to send with a buffer of 65535 bytes.
    The send call fails and the errno is set to EVMSERR. It appears
    the vaxc$errno is set to IVBUFLEN (if the IVBUFLEN errors is displayed
    as part of the INV_TRANSERR error.
    
    You might have the customer ask TCPWare if they know of any
    configuration parameters that should be raised if an IVBUFLEN
    error occurs on a send of 65535 bytes.
1382.2TCPware is lookingCSC32::R_GOLLEHONMon Mar 17 1997 14:2129
    >Is there a reason why everything is repeated 3 times ?
    
    Yes...not being familiar with the trace flags and not having docs
    handy, I turned on A-Z and from what I gather, this caused the messages
    to be written to a file, sys$output (same file) and sys$error (yet
    again).
    
    >Where did the customer see the IVBUFLEN error ? I would have
    >expected to see it after the INV_TRANSERR error message.
    
    For some reason the only place this error is showing up is in the
    DEC/EDI error log.
    
    >OBB is making a call to send with a buffer of 65535 bytes.
    >The send call fails and the errno is set to EVMSERR. It appears
    >the vaxc$errno is set to IVBUFLEN (if the IVBUFLEN errors is displayed
    >as part of the INV_TRANSERR error.
    
    >You might have the customer ask TCPWare if they know of any
    >configuration parameters that should be raised if an IVBUFLEN
    >error occurs on a send of 65535 bytes.

    I'm having them check this out.  The customer related it to the TCPware
    support person, but hte message may have been garbled.  I'm talking to
    them more directly now.
    
    Thanks,
    
    -Robert
1382.3the trace from .0 run through UNIX "uniq" commandVAXCPU::michaudJeff Michaud - ObjectBrokerMon Mar 17 1997 23:1111
    *** Request Sent: Synchronous Invoke.
    *** Method: 68eb4b476f40.0c.70.a9.00.00.00.00.00.
    ***    MethodServerClass: 68eb4b476f3f.0c.70.a9.00.00.00.00.00
    ***    Marshalled Buffer: 66332
    ***    Allocated Buffer : 67611
    --- SAR: Sending message on socket 9
    --- Sending on socket 9
    --- Total data length is 66332
    --- Sending data on socket - len is 65535
    --- Error sending data - error value is 65535
    ***    Transport Status: %OBB-E-INV_TRANSERR, Transport error `$TransportError$