TReqS

one thread for Dispatcher
one thread for Activator
Activator will run up to N stagers i.e. up to N threads (each stager run in one thread)
  N is compute from number of waiting queues and 
  count of simultaneous stagers per  queue (STAGING_DEPTH (=3) in config file) and
  limit in count of drives allocated per type (of drive)

 e.g. 
  40 requests (40 different files) => 40 queues, all using the same model (e.g. T10K-B)
  15 drives allocated for T10K-B
  there will be 1 + 1 + 15 (=stagers) threads 

A lot of (too much ?) abstraction 
Data structures are numerous and heavy, many Map, List, MultiMap !
Some classes have quite the same data members (e.g. FileRequest and PersistenceHelperFileRequest)
Some classes have poor justification (e.g. class User {{ private String name; } !
Naming variables must be done carefully (I mean 'filename' and NOT 'name'). 
Caution with class name
 e.g. File already used is Java classes  hierarchy
 e.g. Resource is too generic (not explicit)
Why Stager is in model package (I recommend control/stager package)
Request | queues status are in DB but also as enum in code (see Request | QueueStatus)
Poor justification for values between .conf.properties and DefaultProperties
e.g. 
  public static final String DEFAULT_DAO_FACTORY = "fr.in2p3.cc.storage." + "treqs.persistance.mysql.MySQLDAOFactory";
  DAO_FACTORY=fr.in2p3.cc.storage.treqs.persistence.mysql.MySQLDAOFactory (in .conf...)
A lot of Exception classes (lot => less readable !)
DAO model is outdated (I recommend using JPA)
A lot of (130) classes !! (besides 63 classes for test code (~400 tests) )

... let's have a cup of coffee ... !