We can connect to Oracle cleanly using the jar file driver and everything works. However, for some reason it's displaying what looks like system tables along with the tables we desire. Has anyone experimented with this connectivity and resolved this issue? It seems odd to me that this is being exposed over ODBC.
New Browser Server
After going live on 64bit Firefox we had a few days with some brownouts and issues that required some changes and tuning. Two things seemed to have corrected the problems and it's running very well now. The original deployment used a NFS directory to be the area to hold temporary files instead of /tmp. This worked fine until a certain number of people and combination of plugins and then the disk io started to bottleneck. With 600 users that can access the Internet, there are thousands of sites they visit each day and it's hard to simulate that during beta testing. I moved the temporary storage back to /tmp and then only copied files to NFS when they were needed by external applications. I stumbled on "iotop" which is a beautiful piece of software. Those of us that used SCO Unix back in the day were always spoiled with "iohog" which performed a similar function.
We also had tuned Firefox with some custom tweaks available on the Internet to increase performance. These too worked in beta testing and under smaller loads, but it looks like when we got over a certain number of concurrent users it flooded the Barracuda, firewalls and eventually the Internet circuit with too many requests at once. When these settings were de-tuned things worked better. Even without them, response time is excellent.
So we have settled in around 80-100 concurrent users in Firefox and here is the load:
The City has "cyber cafes" set up in various places to allow employees to get on the Internet. This was done so that non-work related sites could be visited on breaks and eliminate this being done at their desks. I pointed the thin clients to the new server and have created a point release to our internal build with this feature. I'm testing it this very second and it will go live tomorrow. At that point nearly all services are disabled on the old server and we can begin the process of putting it into retirement.
We use OpenFire for Jabber on our internal instant messenger network. I brought over this software from the old server to discover that it was crashing on 64bit Linux. By default it runs its own included Java, which is only 32bit. All I had to do was modify the openfire rc.d file and add a line to point it to JAVA_HOME. It then ran the 64bit version and is working perfectly. Another item off my list.
Projects on the horizon for me: Upgrading to OpenOffice 3.3 (next week), working with Vincent and Hans on some GNOME issues, getting avant-window-navigator recompiled with all of the latest features, watching for updates to NX 4 to allow us to log into the servers with an iPad.
5 comments:
CTX isn't necessarily a system table. It's an add-on product and is managed really no differently than a homegrown application. PERFSTAT,DBSNMP are other examples.. In fact, most add-ons are built under entirely different schemas, away from the system catalog. All the catalog tables will appear under the SYS schema, if you don't see those, the driver isn't exposing sys tables. A caveat would be the system views which are owned by SYSTEM and dba's/power users would certainly need to see those, but could still be considered system related.
Hi,
it seems that OO get's all visible tables for the current user instead of those, which are in the users' schema (all_tables versus user_tables). This is not an issue, since ctxsys may be useful for users, when they need it. I haven't used OO for database access, but maybe you can change the visible amount of tables to those of the current schema somewhere?
Would you consider posting about your experiences with OpenFire, and how you selected it over other Jabber servers?
OpenFire is VERY stable and just works. I have deployed it for my employer and various other companies that I retain as customers.
@anonymous(s): I was just going to say, OpenFire just works! :) You install the RPM and everything installs cleanly and runs without any having to read any documentation or compile anything. You then just localhost:9090 with Firefox and are setting up user accounts in 5 minutes. It also all sits in /opt/openfire and is very easy to tar up and move to a new server. One other big issue for us was that it has a plugin to record all conversations. This is critical in Government. Many of the other jabber servers have no way to do this. It's very stable and fast, and works extremely well.
If they had a version for 64bit Linux, it wouldn't have taken me the extra five minutes to alter the rc.d startup script. No problems at all on 64bit.
Post a Comment