2013-05-26 71 views
1

我正在使用lucene来存储一些数据的索引。对于在/ home /用户名目录是否存在等下面的代码检查,如果没有发现,从头开始构建创建目录等无法在服务器上创建目录。权限问题?

public static final String INDEX_PATH = "/home/username/appname/lucene/index"; 
private void buildCompleteIndex(int organizationId) { 
     synchronized(mutex) { 
     File path = new File(INDEX_PATH + "/" + String.valueOf(organizationId)); 
     if(!path.exists()) {    
      try { 
       Utils.deleteDirectory(path); 
      } catch (IOException e) { 
       throw new LuceneIndexException("Error rebuilding index directory.", e); 
      } 
      path.mkdirs(); 
     } 

     List<Contact> contactList = contactDAO.findAll(organizationId, true); 
     if(contactList != null) { 
      for(Contact contact : contactList) { 
       add(contact); 
      } 
     } 
    } 
} 

//Getters 
private IndexReader getIndexReader(boolean readOnly, int organizationId) { 
    try { 
     if(directory == null) { 
      File path = getFile(organizationId); 
      directory = FSDirectory.open(path); 
      if(!IndexReader.indexExists(directory)) { 
       buildCompleteIndex(organizationId); 
      } 
     } 
     return IndexReader.open(directory, readOnly); 
    } catch (CorruptIndexException e) { 
     buildCompleteIndex(organizationId); 
    } catch (IOException e) { 
     buildCompleteIndex(organizationId); 
    } 
    return null; 
} 

这一切都在发展中的伟大工程,当我从部署索引eclipse中的虚拟tomcat实例,但在生产服务器上失败。

为什么我能够在开发模式下写入目录,但是当应用程序部署在服务器上时不能写入目录?我没有权限创建目录吗?我正在使用Ubuntu Server 12.10和Tomcat7。

我怎样才能得到这个在服务器上创建正确的文件夹和文件?

是否有一个特定的文件夹,我应该允许我的应用程序在服务器上写入?它始终与我的开发箱上的home/user文件夹一起工作,但也许这在服务器上是不同的,因为用户在应用程序运行时并未实际登录。

更新: 我检查了当前设置为700的文件夹的权限。那可能是问题吗?在生产服务器上将此文件夹设置为666或777安全吗?即使用户名/ home/username没有登录,该文件夹是否可写?我知道700意味着所有者拥有完全访问权限,但是包含tomcat应用程序吗?

更新:我试图将/ home/username的权限更改为755,同样的问题仍然存在。

堆栈跟踪显示尝试创建文件夹时生成的错误。

java.io.IOException: Cannot create directory: /home/ryandlf/thinkbooked.com/lucene/contacts/1 
    at org.apache.lucene.store.NativeFSLock.obtain(NativeFSLockFactory.java:171) 
    at org.apache.lucene.store.Lock.obtain(Lock.java:72) 
    at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108) 
    at com.thinkbooked.search.LuceneContactSearchEngine.getIndexWriter(LuceneContactSearchEngine.java:321) 
    at com.thinkbooked.search.LuceneContactSearchEngine.add(LuceneContactSearchEngine.java:68) 
    at com.thinkbooked.search.LuceneContactSearchEngine.buildCompleteIndex(LuceneContactSearchEngine.java:285) 
    at com.thinkbooked.search.LuceneContactSearchEngine.getIndexReader(LuceneContactSearchEngine.java:303) 
    at com.thinkbooked.search.LuceneContactSearchEngine.find(LuceneContactSearchEngine.java:150) 
    at com.thinkbooked.search.LuceneContactSearchEngine.find(LuceneContactSearchEngine.java:145) 
    at com.thinkbooked.handlers.ClientListSearchHandler.init(ClientListSearchHandler.java:49) 
    at com.thinkbooked.event.EventListener.doPost(EventListener.java:59) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) 
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) 
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) 
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) 
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) 
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) 
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) 
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) 
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) 
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) 
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) 
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) 
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) 
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
    at java.lang.Thread.run(Thread.java:722) 
+1

向我们显示错误。 –

+0

更新了错误。 – ryandlf

+0

您应该先尝试在catch块中添加printStackTrace,并查看导致该异常的原因。然后检查导致无限递归的逻辑。 (也许向我们展示'add()'的代码) –

回答

0

根据我在原始问题中发布的问题得到的答案,在Ubuntu的标准打包版本的tomcat上,tomcat运行在不同的用户名下。要了解这一点,你可以在命令行中使用这个命令:

ps aux | grep catalina 

在我的情况告诉我的用户名tomcat的使用是tomcat7。

要编辑默认的Tomcat用户名,在编辑配置文件:

/etc/default/tomcat7 

第一行应该列出默认的Tomcat用户名和未来的组ID在我的情况是一样的。

要将文件夹的所有权更改为tomcat,以便可以写入目录,请使用chmod命令。

sudo chown -R username:group directory 

-R表示所有子文件夹和文件也将拥有新的所有权。如果你不想要,省略这个。

1

该循环几乎肯定是由某个异常触发的。我在getIndexReader看到一条catch语句,它调用buildCompleteIndex,后者调用add,并且从堆栈跟踪中很容易推断出add可以关闭该循环。要了解问题的根源,您应该了解根本原因。

我不可能知道。首先尝试将:用printStackTrace()System.exit()替换catch块中的所有代码,看看它是否会产生更多关于触发其他所有内容的第一个Exception的有用信息。

+0

我将修复catch块内的stackoverflow。但我仍然认为问题的根源与文件夹没有被创建的事实有关。正如我所提到的,代码在我的开发环境中工作正常。我假设服务器更严格一点,也许我试图写入一个我实际上无法写入的文件夹? – ryandlf

+0

我在问你原始异常的堆栈跟踪,因为我相信Lucene添加了一条错误消息,可以指出问题是什么(但即使没有,也可以知道是否有一个'CorruptIndexException'而不是'IOException',对吧?);没有那个在同一个问题或野蛮猜测过去的经验。 –

+0

我的歉意...更新了stacktrace。 – ryandlf

相关问题