Have you ever run across a problem where you need to debug an issue, but you don't have the relational database setup or the contents to reproduce the issue?  One solution is to ask that persom to export their database and you load it up.  Which, if you done it before, you realize it can take sometime, depending on how much your loading.  And then, at a later date, you need to do it all over again.  Because your data isn't uptodate.   So you can spend a lot of time managing your database. 

Let me suggest an alternative method by using Byteman.  This will enable you to debug the problem on your server, using their data, without having access to their database or having to load their data.   This is accomplished by injecting rules into the Teiid translator framework that will use a Byteman Helper to read and write data to/from the file system.  

The person that is experiencing the problem would first setup their JBoss AS environment by doing the following:

• Start the server
  
• Install the agent
  

               Example:   ./install_agent.sh <pid>   where pid is the process ID (ps -ef | grep jboss)

• [optional] configure the write location by setting property:    org.jboss.byteman.serialize.output.dir='<dir>'

               Example:  ./bsubmit.sh -h localhost -y org.jboss.byteman.serialize.output.dir='<dir>'

              defaults to:  jboss-as/bin/serialize_output

• deploy the Helper classes jar (see test.jar or source.zip)

               Example:  ./bmsubmit.sh -b <path>/test.jar 

• deploy the TranslatorJDBCWriteData.btm rules file
  

               Example:  ./bmsubmit.sh -l <path>/TranslatorJDBCWriteData.btm

Now execute the query.  The data being returned from the data source for each query will be written to the file system location.  You should see 1 folder for each query executed thru the translator.  A hashcode is created for each query and that hashcode is used as the name of the folder.    And for reference purposes, there is one <hashcode>.txt file for each folder.  This file contains the query that corresponds to the data in the folder.   See the server log which should indicate the data is being written.    The results can be then be zipped up and sent to the person for debugging.

Now, in order to reproduce the issue without access to the original data source(s), you will need to create dummy -ds.xml datasource files that have the same JNDI name that is mapped in the Teiid VDB to the source model.   I say dummy, in that the data source only has to exist.  It does not have to contain the same schema or relevant data.   I use an empty HSQL database (see attached Dummy_Source-ds.xml example).   To reproduce the issue and start debugging, do the following:

• unzip the data files to either the default location or a configured location
  
• start server
  
• If the location needs to be configured, then set the property: org.jboss.byteman.serialize.output.dir   as described above
• deploy the dummy -ds.xml files
• deploy the Helper classes jar (see test.jar or source.zip)

               Example:  ./bmsubmit.sh -b <path>/test.jar 

• deploy the TranslatorJDBCReadData.btm rules file

               Example:  ./bmsubmit.sh -l <path>/TranslatorJDBCReadData.btm

Now execute the same query that was producing the error.    The server log should indicate the data is being read from the file system.   Assuming all went perfect, you should see the same exception that the person was first experiencing.    Now you can begin to deploy other rules to assist in debugging the issue and getting to the root of the problem.

This was a good Teiid usecase to use Byteman on.   And I think it can help resolve an old problem of data access in cases where the data has been approved for delivery for debugging.  I"m sure there will be cases where data sensitive issues will come into play, and this will not be an option.  However, we are looking into options for encrypting the results, if needed.  So stay tuned.