Thread: [Sqlrelay-discussion] short write
Brought to you by:
mused
Menu
▾
▴
sqlrelay-discussion
|
From: Matt F. <ma...@eq...> - 2005-08-24 15:30:29
|
I am receiving the message 'aaaah, short write!!!!!' from
librudiments.so using rudiments 0.28.2 and sqlrelay 0.36.4.
I have enabled DEBUG_WRITE in rudiments-0.28.2/src/filedescriptor.C and
here is a sample of the output during error conditions:
22687: string write(5,sjir,4)
bufferedWrite of 4 bytes
writebuffersize=8192
writebufferspace=0
byteswritten=0
bytesunwritten=4
just buffering 0 bytes
safeWrite of 8192 bytes
aaaaah, short write!!!!!
22687: ushort write(5,1)
bufferedWrite of 2 bytes
writebuffersize=8192
writebufferspace=0
byteswritten=0
bytesunwritten=2
just buffering 0 bytes
safeWrite of 8192 bytes
aaaaah, short write!!!!!
I assume writebuffersize=8192 and writebufferspace=8 are default
values. Under normal working conditions writebuffersize is usually less
than 8192 and writebufferspace is always greater than 0. Possibly
memory not being initialized properly? Possibly flaky network card?
Any suggestions?
Thanks,
Matt
|
|
From: Matt F. <ma...@eq...> - 2005-08-24 15:45:38
|
typo in original message: 'I assume...writebufferspace=8 are default values...' should be '...writebufferspace=0...' Matt Flynn wrote: > I am receiving the message 'aaaah, short write!!!!!' from > librudiments.so using rudiments 0.28.2 and sqlrelay 0.36.4. > > I have enabled DEBUG_WRITE in rudiments-0.28.2/src/filedescriptor.C > and here is a sample of the output during error conditions: > 22687: string write(5,sjir,4) > bufferedWrite of 4 bytes > writebuffersize=8192 > writebufferspace=0 > byteswritten=0 > bytesunwritten=4 > just buffering 0 bytes > safeWrite of 8192 bytes > aaaaah, short write!!!!! > 22687: ushort write(5,1) > bufferedWrite of 2 bytes > writebuffersize=8192 > writebufferspace=0 > byteswritten=0 > bytesunwritten=2 > just buffering 0 bytes > safeWrite of 8192 bytes > aaaaah, short write!!!!! > > I assume writebuffersize=8192 and writebufferspace=8 are default > values. Under normal working conditions writebuffersize is usually > less than 8192 and writebufferspace is always greater than 0. > Possibly memory not being initialized properly? Possibly flaky > network card? > > Any suggestions? > > Thanks, > > Matt > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: Firstworks/4access <dav...@fi...> - 2005-08-24 20:00:55
|
Now I remember that code :) To improve performance, the filedescriptor class supports buffered reads and writes. SQL Relay sets up an 8k buffer for both read and write buffers on both server and client sides. When one side tries to write() to the other, the data just gets buffered. When the buffer is full or if flushWriteBuffer() is called, the entire buffer is sent over the network. A short-write condition (ie. if an attempt to write 8192 bytes wrote fewer than 8192 bytes) can occur under several circumstances, most notably if some buffer in the kernel or in the underlying hardware is full, which can happen if the machine's network interfaces are really slammed. The code should just loop back and try to write the remaining data again. Whether the file descriptor is in blocking or non-blocking mode could affect that though. In blocking mode, when looping back and writing again, the write() will block until the device can accept data, but in non-blocking mode, the write() will fall through with another short-write condition which will loop back and retry again, over and over. I'll have to think about that a little. Dave On Wed, 2005-08-24 at 11:45 -0400, Matt Flynn wrote: > typo in original message: 'I assume...writebufferspace=8 are default > values...' should be '...writebufferspace=0...' > > Matt Flynn wrote: > > > I am receiving the message 'aaaah, short write!!!!!' from > > librudiments.so using rudiments 0.28.2 and sqlrelay 0.36.4. > > > > I have enabled DEBUG_WRITE in rudiments-0.28.2/src/filedescriptor.C > > and here is a sample of the output during error conditions: > > 22687: string write(5,sjir,4) > > bufferedWrite of 4 bytes > > writebuffersize=8192 > > writebufferspace=0 > > byteswritten=0 > > bytesunwritten=4 > > just buffering 0 bytes > > safeWrite of 8192 bytes > > aaaaah, short write!!!!! > > 22687: ushort write(5,1) > > bufferedWrite of 2 bytes > > writebuffersize=8192 > > writebufferspace=0 > > byteswritten=0 > > bytesunwritten=2 > > just buffering 0 bytes > > safeWrite of 8192 bytes > > aaaaah, short write!!!!! > > > > I assume writebuffersize=8192 and writebufferspace=8 are default > > values. Under normal working conditions writebuffersize is usually > > less than 8192 and writebufferspace is always greater than 0. > > Possibly memory not being initialized properly? Possibly flaky > > network card? > > > > Any suggestions? > > > > Thanks, > > > > Matt > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > > & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Sqlrelay-discussion mailing list > > Sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
|
From: Matt F. <ma...@eq...> - 2005-08-24 20:26:06
|
in my case it sounds like non-blocking mode, short write loops forever...or at least longer than I have patience to wait to see if it completes. Firstworks/4access wrote: >Now I remember that code :) > >To improve performance, the filedescriptor class supports buffered reads >and writes. SQL Relay sets up an 8k buffer for both read and write >buffers on both server and client sides. When one side tries to write() >to the other, the data just gets buffered. When the buffer is full or >if flushWriteBuffer() is called, the entire buffer is sent over the >network. A short-write condition (ie. if an attempt to write 8192 bytes >wrote fewer than 8192 bytes) can occur under several circumstances, most >notably if some buffer in the kernel or in the underlying hardware is >full, which can happen if the machine's network interfaces are really >slammed. > >The code should just loop back and try to write the remaining data >again. Whether the file descriptor is in blocking or non-blocking mode >could affect that though. In blocking mode, when looping back and >writing again, the write() will block until the device can accept data, >but in non-blocking mode, the write() will fall through with another >short-write condition which will loop back and retry again, over and >over. I'll have to think about that a little. > >Dave > >On Wed, 2005-08-24 at 11:45 -0400, Matt Flynn wrote: > > >>typo in original message: 'I assume...writebufferspace=8 are default >>values...' should be '...writebufferspace=0...' >> >>Matt Flynn wrote: >> >> >> >>>I am receiving the message 'aaaah, short write!!!!!' from >>>librudiments.so using rudiments 0.28.2 and sqlrelay 0.36.4. >>> >>>I have enabled DEBUG_WRITE in rudiments-0.28.2/src/filedescriptor.C >>>and here is a sample of the output during error conditions: >>>22687: string write(5,sjir,4) >>>bufferedWrite of 4 bytes >>> writebuffersize=8192 >>> writebufferspace=0 >>> byteswritten=0 >>> bytesunwritten=4 >>>just buffering 0 bytes >>>safeWrite of 8192 bytes >>>aaaaah, short write!!!!! >>>22687: ushort write(5,1) >>>bufferedWrite of 2 bytes >>> writebuffersize=8192 >>> writebufferspace=0 >>> byteswritten=0 >>> bytesunwritten=2 >>>just buffering 0 bytes >>>safeWrite of 8192 bytes >>>aaaaah, short write!!!!! >>> >>>I assume writebuffersize=8192 and writebufferspace=8 are default >>>values. Under normal working conditions writebuffersize is usually >>>less than 8192 and writebufferspace is always greater than 0. >>>Possibly memory not being initialized properly? Possibly flaky >>>network card? >>> >>>Any suggestions? >>> >>>Thanks, >>> >>>Matt >>> >>> >>>------------------------------------------------------- >>>SF.Net email is Sponsored by the Better Software Conference & EXPO >>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle >>>Practices >>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing >>>& QA >>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >>>_______________________________________________ >>>Sqlrelay-discussion mailing list >>>Sql...@li... >>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >>> >>> >>> >> >>------------------------------------------------------- >>SF.Net email is Sponsored by the Better Software Conference & EXPO >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >>_______________________________________________ >>Sqlrelay-discussion mailing list >>Sql...@li... >>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion >> >> >> > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >Sqlrelay-discussion mailing list >Sql...@li... >https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > |
|
From: David M. <dav...@fi...> - 2005-08-26 03:22:20
|
You might give http://www.firstworks.com/sqlrelay-0.37pre2.tar.gz a try. I think I fixed the aaaah, short write bug. It's a pre-release though, so keep that in mind :) Dave On Wed, 2005-08-24 at 16:25 -0400, Matt Flynn wrote: > in my case it sounds like non-blocking mode, short write loops > forever...or at least longer than I have patience to wait to see if it > completes. > > Firstworks/4access wrote: > > >Now I remember that code :) > > > >To improve performance, the filedescriptor class supports buffered reads > >and writes. SQL Relay sets up an 8k buffer for both read and write > >buffers on both server and client sides. When one side tries to write() > >to the other, the data just gets buffered. When the buffer is full or > >if flushWriteBuffer() is called, the entire buffer is sent over the > >network. A short-write condition (ie. if an attempt to write 8192 bytes > >wrote fewer than 8192 bytes) can occur under several circumstances, most > >notably if some buffer in the kernel or in the underlying hardware is > >full, which can happen if the machine's network interfaces are really > >slammed. > > > >The code should just loop back and try to write the remaining data > >again. Whether the file descriptor is in blocking or non-blocking mode > >could affect that though. In blocking mode, when looping back and > >writing again, the write() will block until the device can accept data, > >but in non-blocking mode, the write() will fall through with another > >short-write condition which will loop back and retry again, over and > >over. I'll have to think about that a little. > > > >Dave > > > >On Wed, 2005-08-24 at 11:45 -0400, Matt Flynn wrote: > > > > > >>typo in original message: 'I assume...writebufferspace=8 are default > >>values...' should be '...writebufferspace=0...' > >> > >>Matt Flynn wrote: > >> > >> > >> > >>>I am receiving the message 'aaaah, short write!!!!!' from > >>>librudiments.so using rudiments 0.28.2 and sqlrelay 0.36.4. > >>> > >>>I have enabled DEBUG_WRITE in rudiments-0.28.2/src/filedescriptor.C > >>>and here is a sample of the output during error conditions: > >>>22687: string write(5,sjir,4) > >>>bufferedWrite of 4 bytes > >>> writebuffersize=8192 > >>> writebufferspace=0 > >>> byteswritten=0 > >>> bytesunwritten=4 > >>>just buffering 0 bytes > >>>safeWrite of 8192 bytes > >>>aaaaah, short write!!!!! > >>>22687: ushort write(5,1) > >>>bufferedWrite of 2 bytes > >>> writebuffersize=8192 > >>> writebufferspace=0 > >>> byteswritten=0 > >>> bytesunwritten=2 > >>>just buffering 0 bytes > >>>safeWrite of 8192 bytes > >>>aaaaah, short write!!!!! > >>> > >>>I assume writebuffersize=8192 and writebufferspace=8 are default > >>>values. Under normal working conditions writebuffersize is usually > >>>less than 8192 and writebufferspace is always greater than 0. > >>>Possibly memory not being initialized properly? Possibly flaky > >>>network card? > >>> > >>>Any suggestions? > >>> > >>>Thanks, > >>> > >>>Matt > >>> > >>> > >>>------------------------------------------------------- > >>>SF.Net email is Sponsored by the Better Software Conference & EXPO > >>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>>Practices > >>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing > >>>& QA > >>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > >>>_______________________________________________ > >>>Sqlrelay-discussion mailing list > >>>Sql...@li... > >>>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >>> > >>> > >>> > >> > >>------------------------------------------------------- > >>SF.Net email is Sponsored by the Better Software Conference & EXPO > >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > >>_______________________________________________ > >>Sqlrelay-discussion mailing list > >>Sql...@li... > >>https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > >> > >> > >> > > > > > > > >------------------------------------------------------- > >SF.Net email is Sponsored by the Better Software Conference & EXPO > >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > >_______________________________________________ > >Sqlrelay-discussion mailing list > >Sql...@li... > >https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > > > > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Sqlrelay-discussion mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlrelay-discussion > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X