I have a polling route for FTP like this
from("sftp://sftpUsername#ftpServer/path/to/folder?password=sftpPassword
&delay=60000&stepwise=false&move=/home/username/processed/$simple{date:now:yyyy}
/$simple{date:now:MM}/$simple{date:now:dd}/${file:name}&binary=true")
.to("file:///tmp/")
The polling is working as expected. I was able to move the processed files to a sub folder inside the /path/to/folder. However, when I tried to move it to a different folder location. I'm getting an exception. Unfortunately, the exception is not detailed.
DEBUG org.apache.camel.component.file.GenericFileOnCompletion - Done processing file: RemoteFile[/path/to/folder/fileName.zip] using exchange: Exchange[fileName.zip]
DEBUG org.apache.camel.component.file.remote.FtpOperations - Deleting file: /home/username/processed/2017/07/11/fileName.zip
TRACE org.apache.camel.component.file.remote.FtpOperations - Client deleteFile: /home/username/processed/2017/07/11/fileName.zip
TRACE org.apache.camel.component.file.remote.FtpOperations - buildDirectory(/home/username/processed/2017/07/11)
TRACE org.apache.camel.component.file.remote.FtpOperations - changeCurrentDirectory(/home/username)
TRACE org.apache.camel.component.file.remote.FtpOperations - Changing directory: /home/username
DEBUG org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy - Renaming file: RemoteFile[/path/to/folder/fileName.zip] to: RemoteFile[/home/username/processed/2017/07/11/fileName.zip]
DEBUG org.apache.camel.component.file.remote.FtpOperations - Renaming file: /path/to/folder/fileName.zip to: /home/username/processed/2017/07/11/fileName.zip
WARN org.apache.camel.component.file.GenericFileOnCompletion - Error during commit. Exchange[fileName.zip]. Caused by: [org.apache.camel.component.file.GenericFileOperationFailedException - Cannot rename file: RemoteFile[/path/to/folder/fileName.zip] to: RemoteFile[//home/username/processed/2017/07/11/fileName.zip]]
org.apache.camel.component.file.GenericFileOperationFailedException: Cannot rename file: RemoteFile[/path/to/folder/fileName.zip] to: RemoteFile[/home/username/processed/2017/07/11/fileName.zip]
at org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:115)
I'm using Camel-FTP 2.13.4 which uses commons.net-3.3.jar. I could see that it is trying to do RNFR and RNTO command. I was not able to use those command from command line FTP protocol.
If I understand correctly we can use absolute paths in 2.13.4 version. Please let me know, if this understanding is incorrect.
Thanks in advance for any help in the right direction.
This didn't work as the partition is different and we cannot move a file between partitions. The option is to either move the file to a location in the same partition. Or you could manually FTP it back to a location on different partition.
Related
I am processing some documents and I am getting many WORKDAY messages as seen below.
There's a similar issue posted here for WEEKDAY. Does anyone know how to deal with this message. I am running corenlp in a Java server on Windows and accessing it using Juypyter Notebook and Python code.
[pool-2-thread-2] INFO edu.stanford.nlp.ling.tokensregex.types.Expressions - Unknown variable: WORKDAY
[pool-2-thread-2] INFO edu.stanford.nlp.ling.tokensregex.types.Expressions - Unknown variable: WORKDAY
[pool-2-thread-2] INFO edu.stanford.nlp.ling.tokensregex.types.Expressions - Unknown variable: WORKDAY
[pool-1-thread-7] WARN CoreNLP - java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error making document
This is an error in the current SUTime rules file (and it's actually been there for quite a few versions). If you want to fix it immediately, you can do the following. Or we'll fix it in the next release. These are Unix commands, but the same thing will work elsewhere except for how you refer to and create folders.
Find this line in sutime/english.sutime.txt and delete it. Save the file.
{ (/workday|work day|business hours/) => WORKDAY }
Then move the file to the right location for replacing in the jar file, and then replace it in the jar file. In the root directory of the CoreNLP distribution do the following (assuming you don't already have an edu file/folder in that directory):
mkdir -p edu/stanford/nlp/models/sutime
cp sutime/english.sutime.txt edu/stanford/nlp/models/sutime
jar -uf stanford-corenlp-4.2.0-models.jar edu/stanford/nlp/models/sutime/english.sutime.txt
rm -rf edu
SonarQube 6.0 Installation
No plugins currently installed
Presently working through what appears to be connect string problem
In a command prompt, running as Administrator, I enter
StartSonar
This fails with rather cryptic output to the Command Prompt window. The following is what I believe is the relevant excerpt from the sonar.log file:
2016.08.11 12:23:29 INFO web[o.sonar.db.Database] Create JDBC data source for jdbc:sqlserver://localhost/DevOps;databaseName=sonar
2016.08.11 12:23:43 ERROR web[o.a.c.c.C.[.[.[/sonar]] Exception sending context initialized event to listener instance of class org.sonar.server.platform.PlatformServletContextListener
java.lang.IllegalStateException: Can not connect to database. Please check connectivity and settings (see the properties prefixed by 'sonar.jdbc.').
at org.sonar.db.DefaultDatabase.checkConnection(DefaultDatabase.java:104) ~[sonar-db-6.0.jar:na]
at org.sonar.db.DefaultDatabase.start(DefaultDatabase.java:71) ~[sonar-db-6.0.jar:na]
Relevant excerpt from .config file:
sonar.jdbc.url=jdbc:sqlserver://localhost/DevOps:1433;databaseName=sonar
sonar.jdbc.username=SonarQube
sonar.jdbc.password=PassWord1234
Finally, victory is mine! To be fair, I looked at the .config file from TeamCity. Thanks JetBrains!
The correct entries from the .config file (Note backslash / escape characters!):
sonar.jdbc.url=jdbc\:sqlserver\://localhost\\DevOps\:1433;databaseName\=Sonar
sonar.jdbc.username=SonarQube
sonar.jdbc.password=PassWord1234
I'm in the process of executing Maven commands to run tests in the console (MacOSX). Recently, development efforts have produced extraneous messages in the console (info, debug, warning, etc.) I'd like to know how to remove messages like this:
INFO c.c.m.s.c.p.ApplicationProperties - Loading application properties from: app-config/shiro.properties
I've used this code to remove messages from the dbunit tests:
ch.qos.logback.classic.Logger Logger = (ch.qos.logback.classic.Logger)LoggerFactory.getLogger("org.dbunit");
Logger.setLevel(Level. ERROR);
However, I'm unsure how to disable these additional (often verbose and irritating) messages from showing up on the console so that I can see the output more easily. Additional messages appear as above and these:
DEBUG c.c.m.s.c.f.dao.AbstractDBDAO - Adding filters to the Main Search query.
WARN c.c.m.s.c.p.JNDIConfigurationProperties - Unable to find JNDI value for name: xxxxx
INFO c.c.m.a.t.d.DatabaseTestFixture - * executing sql: xxxxx
The successful answer was:
SOLUTION: Solution to issue IS adding a 'logback-test.xml' file to the root of my test folder. I used the default contents (as instructed by the documentation - thanks #Charlie). Once file exists there, FIXED!
Sometimes Glassfish - OpenESB-v2.3 gives following error:
jbi-registry.xml:1:1: Premature end of file.
What did happen here?
This occurs sometimes when the Server or Glassfish restarts or have not correct shutdown (sometime Windows Update forced restarts). Then the file jbi-registry.xml is empty and we get above error.
To correct it, just go to the following folder:
%GLASSFISH_ESB%/glassfish/domains/domain1/jbi/config
And check if the jbi-registry.xml is empty. If this is the case, replace it with the jbi-registry-backup.xml which is located in the same directory and should not be empty.
I'm using Teamcity 5 for our CI environment. It's a great tool, but I've been struggling with one thing: the stdout_yyyyMMdd.log file in the \TeamCity\logs folder grows to ridiculous sizes. Is there a way to turn it off?
Places I've looked so far:
Jetbrains: Nothing on stdout;
Google for "tomcat stdout logs": the first few links don't really address the issue.
Edit:
At KIR's suggestion, I actually looked to see what's in stdout. It's the same exception message repeated over and over again:
[2010-12-01 08:57:21,268] WARN - jetbrains.buildServer.SERVER - java.io.FileNotFoundException: <...Path...>\.BuildServer\system\caches\search\_8p.prx (The system cannot find the file specified)
[2010-12-01 08:57:21,315] ERROR - erverSide.search.SearchService - SearchService.enqueueHistory
java.io.FileNotFoundException: <...Path...>\.BuildServer\system\caches\search\_8p.prx (The system cannot find the file specified)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.<init>(Unknown Source)
at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput$Descriptor.<init>(SimpleFSDirectory.java:78)
at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput.<init>(SimpleFSDirectory.java:108)
at org.apache.lucene.store.SimpleFSDirectory.openInput(SimpleFSDirectory.java:65)
at org.apache.lucene.index.SegmentReader$CoreReaders.<init>(SegmentReader.java:132)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:638)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:599)
at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:104)
at org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:27)
at org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:74)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:704)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:69)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:476)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:314)
at jetbrains.buildServer.serverSide.search.SearchService.getIndexSearcher(SearchService.java:451)
at jetbrains.buildServer.serverSide.search.SearchService.enqueueHistory(SearchService.java:515)
at jetbrains.buildServer.serverSide.search.BackgroundIndexer.run(BackgroundIndexer.java:32)
at java.lang.Thread.run(Unknown Source)
Any idea what this file is?
If you're running TC on unix you could use logrotate: http://linuxcommand.org/man_pages/logrotate8.html (Obviously, this is a workaround but it should be effective.)
This guy has a windows equivalent that may do the trick too: http://www.datori.org/?p=7
Remove .BuildServer\system\caches\search directory and restart TeamCity. May be this would help.
The problem is caused by someone or something deleting the Lucene Index in Team city.
Everytime you hit a page after this it will log in stdout that it couldnt find the file.
If you clear out the whole folder which should be
%USERPROFILE%.BuildServer\system\caches\search\
See http://confluence.jetbrains.net/display/TCD5/TeamCity+Data+Directory for more information on where to find the folder.
And restart Teamcity it will recreate the index on start up and stop logging the error message.
Oh and search should start working again too.