Transferring things between Virtualbox host and guest machines

If you want to transfer text or image between host and guest (or vice versa), the simplest way is good old copy and paste. 

Fortunately, Virtualbox already has a feature that allows us to do so. To enable it, first you need to install the Virtual Box Guest Additions. 

On your guest machine, go to the top menu and choose **Devices** and then **Insert Guest Additions CD Image...**.

Installing guest additions, however, isn't enough to enable copy and paste. You now need to enable it in the virtual machine settings. 

Select your machine in Virtualbox, then click on **Settings**. On the settings window, click on the **General** menu and then **Advanced**. What you are looking for is **Shared Clipboard**.

Even though copy and paste is fantastic, currently it doesn't work for files. To be able to move files between your host and guest machines you can enable **Drag'n'Drop** on the same tab. It works like charm in my linux system.

Solr update / sunspot commit way too slow

We have recently updated one of our applications to ruby 2.1.2 and rails 3.2 and, as part of the process, updated most of the gems used. One of the gems updated was sunspot, from 1.3.0 to 2.1.0.

After this update we started experiencing terrible performance in solr update when running a sunspot commit. And by terrible I mean awful. 45s average per commit.

If you are experiencing something like this too, here are some tips (and, at the end, the solution to our problem):

• Check if your system has enough free memory. If you are swapping, that could be your problem.

• If you use the sunspot-solr gem to start solr, run it in the foreground to get the full log on your screen and try to identify which step is taking long (in our case it was SpellChecker):

sunspot-solr -s /my_app/shared/solr/ -d /my_app/shared/solr/data --pid-dir=/my_app/shared/pids/ run 

will start solr in the foreground.

• In the configuration file, solrconfig.xml, check if the values of autoCommit.maxTime and autoSoftCommit.maxTime aren't to low:

         <autoCommit>

           <maxTime>60000</maxTime>

         </autoCommit>

         <autoSoftCommit>

           <maxTime>15000</maxTime>

         </autoSoftCommit>

To be honest, I don't know what are the ideal values for them, but 60s between each autoCommit and 15s between each softCommit seemed fine for our purposes.

• Check if the value of the autowarmCount property for the caches is not too high. In our case, it was 0 and so it remained.

autowarmCount="0"

• Check if the automatic building of the spellcheck dictionary on every commit is not enabled. In our case, that was the culprit! This is a very expensive operation and it was being invoked after every single commit. We simply changed the property buildOnCommit of the spellchecker to false and the average commit time dropped to 19ms. Excellent!

Performance killer:

<str name="buildOnCommit">true</str>

Way to go:

<str name="buildOnCommit">false</str>

Just as an observation, buildOnCommit = true was the default value on the configuration file generated by sunspot-solr.

How to flatten a zip file directory structure

This is short but super useful. 

If you have a zip file with a directory structure but want all the files to be extracted in the same folder, use the 'junk paths' parameter (-j). It will extract all the files in the zip file to the current folder, completely disregarding the directory structure.

Example:

 unzip -l myrubygems.zip

  Length      Date    Time    Name
---------  ---------- -----   ----
    27136  2015-08-14 16:05   dist/cache/actionmailer-4.2.3.gem
   185344  2015-08-14 16:05   dist/cache/actionpack-4.2.3.gem
   144896  2015-08-14 16:05   dist/cache/actionview-4.2.3.gem
    18944  2015-08-14 16:05   dist/cache/activejob-4.2.3.gem
    45568  2015-08-14 16:05   dist/cache/activemodel-4.2.3.gem
   327680  2015-08-14 16:05   dist/cache/activerecord-4.2.3.gem
   329728  2015-08-14 16:03   dist/cache/activesupport-4.2.3.gem

 unzip -j myrubygems.zip 

  inflating: actionmailer-4.2.3.gem  
  inflating: actionpack-4.2.3.gem    
  inflating: actionview-4.2.3.gem    
  inflating: activejob-4.2.3.gem     
  inflating: activemodel-4.2.3.gem   
  inflating: activerecord-4.2.3.gem  
  inflating: activesupport-4.2.3.gem  

ORA-01653: unable to extend table by in tablespace SYSTEM

If you get ORA-01653 when trying to insert data into the database, that means Oracle DB was unable to extend your tablespace, either because it reached its maximum allowed space or because autoextend is not enabled.

To solve that, first check the size of the datafiles attached to the tablespace and whether they can autoextend or not:

 select file_name, bytes, autoextensible, maxbytes from dba_data_files where
 tablespace_name='SYSTEM';

Then, add more space to that file:

 alter database datafile '/u01/app/oracle/oradata/XE/system.dbf' resize 1000m;  

And, turn the autoextend feature on:

 alter database datafile '/u01/app/oracle/oradata/XE/system.dbf' autoextend
 on next 100m maxsize 2000m;  

Alternatively, you can add a new datafile to the tablespace:

 alter tablespace SYSTEM add datafile '/u01/app/oracle/oradata/XE/system2.dbf' 
 size 100m autoextend on next 100m maxsize 2000m;

Oracle expdp error: directory object parameter must be specified and non-null

When dumping a database as an non-privileged user (grants: CONNECT, RESOURCE) using Oracle Data Pump tool I got the following error:

 expdp tax_data/<passwd> schemas=tax_data dumpfile=tax_data.dmp logfile=expdp_tax_data.log  

 ORA-39002: invalid operation  
 ORA-39070: Unable to open the log file.  
 ORA-39145: directory object parameter must be specified and non-null  

This happens because non-privileged users don't have access to the DATA_PUMP_DIR directory object. To solve that all I had to do was grant the roles EXP_FULL_DATABASE and IMP_FULL_DATABASE to the user.

If the DATA_PUMP_DIR has not been created by a DBA beforehand, one would get a different message:

 ORA-39002: invalid operation   
 ORA-39070: Unable to open the log file.   
 ORA-39087: directory name DATA_PUMP_DIR is invalid   

To check what is the value of the DATA_PUMP_DIR:

 select * from dba_directories where DIRECTORY_NAME = 'DATA_PUMP_DIR';  

JSP encoding error on weblogic server

If you are getting the error:

The encoding specified on the page cannot be different than detected encoding for the file.

<%@ page contentType="text/html; charset=utf-8" pageEncoding="utf-8" %>

during JSP compilation by weblogic, chances are weblogic is not recognizing your file encoding correctly. To solve that, put the encoding tag at the very top of your JSP file:

<%@ page contentType="text/html; charset=utf-8" pageEncoding="utf-8" %>

And when I say very top, I mean the very first declaration before any other declarations in the jsp. Weblogic expects the page encoding tag to be the first declaration on file:

Wrong:

<%@ page import="com.mycompany.blabla"%>

<%@ page contentType="text/html; charset=utf-8" pageEncoding="utf-8" %>

Right:

<%@ page contentType="text/html; charset=utf-8" pageEncoding="utf-8" %>
<%@ page import="com.mycompany.blabla"%>

The following excerpt was extracted from a stackoverflow question (http://stackoverflow.com/questions/3141410/weblogic-throws-compilationexception): 

"It's more than just rearranging those two lines. Actually, it's not even a rearrangement, but more like moving that directive to the very top of everything else. The JSP directive containing the pageEncoding MUST BE the very first thing in the file. That means you cannot have JSP blocks, JSP directives, JSP comments or anything before that. Anything!"

The encoding error can also happen to tag libraries. In that case, put the following tag at the very top of your file:

<%@tag description="Component Info tag for Taxrules" pageEncoding="UTF-8"%>