Tuesday, June 30, 2009
IBPhoenix Web Site
I need to post a note on my blog about the IBPhoenix Web site, it seems we are having problems with the T1 line. It looks like there is a problem in the central phone office, where our T1 line originates. It's been a problem now for several days. The issue has been escalated, so hopefully things will improve shortly.
Thursday, June 25, 2009
../src/include/types_pub.h:88: error: conflicting declaration 'typedef int ISC_LONG'
Building Firebird 64bit on Solaris (sparc or intel) can sometimes produce the following error:
-c ../src/jrd/dsc.cpp -o ../temp/boot/jrd/dsc.o
../src/include/types_pub.h:88: error: conflicting declaration 'typedef int ISC_LONG'
../src/include/fb_types.h:69: error: 'ISC_LONG' has a previous declaration as 'typedef SLONG ISC_LONG'
../src/include/types_pub.h:89: error: conflicting declaration 'typedef unsigned int ISC_ULONG'
../src/include/fb_types.h:70: error: 'ISC_ULONG' has a previous declaration as 'typedef ULONG ISC_ULONG
If you see this - then you made a mistake in the build process. Configure.in when you invoked it, assumed that the size of long was 4, and you are attempting to build Firebird for a 32bit environment. As per the prefix.solaris files, you must set the following before running configure:
export CXXFLAGS='-m64'
export CFLAGS='-m64'
export LDFLAGS='-m64'
Configure will now automtically realise that you want to build in a 64 bit environment and set the size of long to 8.
-c ../src/jrd/dsc.cpp -o ../temp/boot/jrd/dsc.o
../src/include/types_pub.h:88: error: conflicting declaration 'typedef int ISC_LONG'
../src/include/fb_types.h:69: error: 'ISC_LONG' has a previous declaration as 'typedef SLONG ISC_LONG'
../src/include/types_pub.h:89: error: conflicting declaration 'typedef unsigned int ISC_ULONG'
../src/include/fb_types.h:70: error: 'ISC_ULONG' has a previous declaration as 'typedef ULONG ISC_ULONG
If you see this - then you made a mistake in the build process. Configure.in when you invoked it, assumed that the size of long was 4, and you are attempting to build Firebird for a 32bit environment. As per the prefix.solaris files, you must set the following before running configure:
export CXXFLAGS='-m64'
export CFLAGS='-m64'
export LDFLAGS='-m64'
Configure will now automtically realise that you want to build in a 64 bit environment and set the size of long to 8.
Wednesday, June 24, 2009
Some Positive Feedback for Firebird
This message appeared on the Firebird Development list, from Jens Zurawski
"I think from time to time, one should really send some positive feedback
to the people who are involved into the development of the firebird
DBMS. Thank you very much for your efforts to make this software this good!
Just before a week or so we eventually upgraded our production server
from linux kernel 2.4 to 2.6.x and the firebird engine from 2.0.x to
2.1.2. As some of you might remember, long time ago we had some big
troubles with kernel 2.6.x and firebird, because our system is under
very heavy contention and we stumbled over many freezes, so we were
stuck to the 2.4.x kernel. (In average there are 75-150 simultaneous
connections to one database, in peak times up to 300. The database is
more than 20GBs in size and is serving for a pool of approx. 7 different
applications, starting from web server (php/java) over some internal
logistics processings (java) up to the CRM front end (Win32 native), and
additionally there are frequent update tasks with long running
transactions (about 10-30 minutes) and massive changes to the database
records in them).
Now our old database server broke down (hardware problem) and we had to
buy a new one and this time we needed to go for a 2.6.x kernel because
the new hardware was not supported from the old kernel. To my pleasant
surprise, the actual FB 2.1.2 is working very well with a 2.6 kernel and
the heavy contention we still have on our database. Only thing one has
to do is to dramatically increase the semaphores. In the first place we
increased the LockSemCount to 250 (which was the limit of the default
kernel setup) but that wasn't enough. After half of the day firebird
crashed down with a "Fatal lock manager error: semop failed (acquire),
errno: 22", accepted no more new connections and also didn't serve the
existing connections any more. Now after we increased the kernel limit
and set the LockSemCount up to 1024, everything is working very well. No
more freezes, no more crashes. (BTW: ironically this hint I was getting
from a guy who just has collected some experiences with an Oracle
installation on Linux ;-)
So, what I want to say: Thanks a lot for all the good work! firebird is
really my most favourite open source project.
Ah, and the new monitoring tables in FB 2.1 are a gift from heaven! Now
I'm able to track down problems from applications which are not written
by me, because now I can simply monitor hanging transactions or long
running "sub-optimal" queries and send the developer a hint ;) Also
thanks a lot for this feature!"
"I think from time to time, one should really send some positive feedback
to the people who are involved into the development of the firebird
DBMS. Thank you very much for your efforts to make this software this good!
Just before a week or so we eventually upgraded our production server
from linux kernel 2.4 to 2.6.x and the firebird engine from 2.0.x to
2.1.2. As some of you might remember, long time ago we had some big
troubles with kernel 2.6.x and firebird, because our system is under
very heavy contention and we stumbled over many freezes, so we were
stuck to the 2.4.x kernel. (In average there are 75-150 simultaneous
connections to one database, in peak times up to 300. The database is
more than 20GBs in size and is serving for a pool of approx. 7 different
applications, starting from web server (php/java) over some internal
logistics processings (java) up to the CRM front end (Win32 native), and
additionally there are frequent update tasks with long running
transactions (about 10-30 minutes) and massive changes to the database
records in them).
Now our old database server broke down (hardware problem) and we had to
buy a new one and this time we needed to go for a 2.6.x kernel because
the new hardware was not supported from the old kernel. To my pleasant
surprise, the actual FB 2.1.2 is working very well with a 2.6 kernel and
the heavy contention we still have on our database. Only thing one has
to do is to dramatically increase the semaphores. In the first place we
increased the LockSemCount to 250 (which was the limit of the default
kernel setup) but that wasn't enough. After half of the day firebird
crashed down with a "Fatal lock manager error: semop failed (acquire),
errno: 22", accepted no more new connections and also didn't serve the
existing connections any more. Now after we increased the kernel limit
and set the LockSemCount up to 1024, everything is working very well. No
more freezes, no more crashes. (BTW: ironically this hint I was getting
from a guy who just has collected some experiences with an Oracle
installation on Linux ;-)
So, what I want to say: Thanks a lot for all the good work! firebird is
really my most favourite open source project.
Ah, and the new monitoring tables in FB 2.1 are a gift from heaven! Now
I'm able to track down problems from applications which are not written
by me, because now I can simply monitor hanging transactions or long
running "sub-optimal" queries and send the developer a hint ;) Also
thanks a lot for this feature!"
Subscribe to:
Posts (Atom)