Starting in GS/64 2.4, a change was made in socket behavior that causes
an exception to be raised in the GbjBroker when the "gslist -v" command
pings the GbjBroker's socket. The GbjBroker traps the exception and continues
normally, but the resulting error message and stack traces will clutter
up the GbjBroker log, and there is a tiny increase in memory allocation.
This is normally not a problem for most customers, but those that make
extensive use of "gslist -v" for monitoring the GbjBroker status may note
the memory growth over an extended period of time.
File-in and commit the following code as SystemUser:
! Fix for bug 40956
! Perform a socket read: 0 call and check result
! against zero before performing isConnected
!
category: 'Servicing'
method: GsbServerSocket
establishService: aGsbClientSocket
"Establish a service for aGsbClientSocket."
| fw |
fw := self framework.
" 40956: add read: 0 check "
(((aGsbClientSocket read: 0 into: String new) = 0) and:
[aGsbClientSocket isConnected]) ifFalse: [
" The new socket disconnected, probably from a gslist -v query.
Just clean it up using a low-level close. "
(fw configuration at: #verbose) ifTrue: [
fw log: #GsbClientSocketDisconnected
arguments: #[aGsbClientSocket]].
aGsbClientSocket _zeroArgPrim: 2.
^ self ].
aGsbClientSocket linger: true length: 10. "*** TODO *** Why 10?"
(fw configuration at: #verbose) ifTrue: [
fw log: #GsbClientSocketConnectionEstablished
arguments: #[aGsbClientSocket, GsbFramework dateTimeNow]].
self serviceBlock value: aGsbClientSocket
%
Last updated: 10/1/10