Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FTP - toPath sink #182 #184

Merged
merged 1 commit into from
Mar 24, 2017
Merged

Conversation

svezfaz
Copy link
Contributor

@svezfaz svezfaz commented Feb 13, 2017

Handles #182

@@ -97,4 +99,47 @@ trait CommonFtpSourceSpec extends BaseSpec {
}
}

"FtpIOSink" should {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it worth having a spec showing the "sad path?" maybe an IOException when trying to write to a location without sufficient permissions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for reviewing, that's a fair point

maybe I could leave the anon user with writepermissions=false for the sad path + setup a different, write-enabled user for the happy path?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@svezfaz That would be great!.

Copy link
Contributor Author

@svezfaz svezfaz Feb 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can easily manage FtpServer permissions with the users.properties file, but still haven't worked out how to do it for Sshd/Jimfs (SFTP tests).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't done yet either. It seems that you can control the permissions set with chmod.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juanjovazquez @eharik I tried several approaches, chmod being one of them. But ultimately, the underlying filesystem is Jimfs - which does not support posix-like permissions.

For example, while setting and reading POSIX file permissions is possible with the "posix" view, those permissions will not actually affect the behavior of the file system.

I don't see an easy way of testing this without moving to - say - Memoryfilesystem.
The good news is that - somehow obviously - when trying it with my local filesystem, I get IOExceptions for permission errors.

WDYT?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what Akka members team will think, but seeing that it is so difficult to test this particular case, I would let it be. I'd stick to jimfs as it's been very rewarding up until now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good to keep it simple, and stick to jimfs

Copy link

@juanjovazquez juanjovazquez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from these nitpicks, the PR LGTM. Great contribution!. I love dualities ;-).

import akka.stream.stage.{GraphStageWithMaterializedValue, OutHandler}
import akka.stream.{Attributes, IOResult, Outlet, SourceShape}
import akka.stream.stage.{GraphStageWithMaterializedValue, InHandler, OutHandler}
import akka.stream._

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd go with single type imports instead of on-demand style with the underscore. I'm not sure if there's a general policy for this.

import akka.stream.impl.Stages.DefaultAttributes.IODispatcher
import akka.util.ByteString
import akka.util.ByteString.ByteString1C

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this blank line?.

import java.nio.file.Path

private[ftp] trait FtpIOGraphStage[FtpClient, S <: RemoteFileSettings]
extends GraphStageWithMaterializedValue[SourceShape[ByteString], Future[IOResult]] {
private[ftp] trait FtpIOGraphStage[FtpClient, S <: RemoteFileSettings, Sh <: Shape]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea to abstract over Shape. ;-)

@@ -97,4 +99,47 @@ trait CommonFtpSourceSpec extends BaseSpec {
}
}

"FtpIOSink" should {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@svezfaz That would be great!.

@juanjovazquez
Copy link

BTW, It seems that #185 is still happening. I'm not able to reproduce it on my side. Maybe we should relax the PatienceConfig a bit more on CommonFtpSourceSpec trait. Maybe something like this?:

implicit val defaultPatience =
    PatienceConfig(timeout = Span(20, Seconds), interval = Span(900, Millis))

@svezfaz svezfaz force-pushed the 182-FTP-toPath-sink branch from 6c4a544 to 4b5ba5f Compare February 13, 2017 22:12
@svezfaz
Copy link
Contributor Author

svezfaz commented Feb 13, 2017

@juanjovazquez I have mixed-in IntegrationPatience to the relevant test to address the flaky tests.

@svezfaz svezfaz force-pushed the 182-FTP-toPath-sink branch 2 times, most recently from 6425a59 to cf97e05 Compare February 16, 2017 18:44
Copy link
Member

@johanandren johanandren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some feedback&questions.

protected[this] def matFailure(t: Throwable): Boolean =
matValuePromise.trySuccess(IOResult.createFailed(writtenBytesTotal, t))

/** BLOCKING I/O WRITE */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, it already runs on a separate dispatcher from the stage superclass right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct.

pull(in)
} else
tryOs.failed.foreach { case NonFatal(t) => throw t }
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just mimics regular exception handling in a more complicated way. What about just calling get on the returned Try of storeFileStream, it will throw the exception if there is one and return the OutputStream if there is one.

* @return A [[Sink]] of [[ByteString]] that materializes to a [[CompletionStage]] of [[IOResult]]
*/
def toPath(
path: Path,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is java.nio.Path really a good type to use here? The parameter refers to the path on the FTP server, while Path instances always has a FileSystem (which does not belong to the FTP server). Won't that mean that path.toAbsolutePath.toString likely will contain "C:\my\path" on windows for example?

I think it should just be a string, or a domain specific path-like type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that makes sense. String path is also used in the ls Sinks already.

@juanjovazquez any particular reason why this was applied to fromPath ?

I can go ahead and use String in both fromPath and toPath.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@svezfaz IIRC that idea also came from Camel. But, I think @johanandren 's considerations make sense. I had that doubt during the first implementation and now I realize that I took the wrong path after all. So, @svezfaz go ahead with these changes if you are willing to. Thanks!.

PosixFilePermissions.fromString("rwxrwxrwx");
FileAttribute<Set<PosixFilePermission>> attr =
PosixFilePermissions.asFileAttribute(perms);
Files.createDirectory(path, attr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this will only ever be called on a Posix/unixy file system?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This bit is actually only used in tests within a Unix-configured Jimfs instance. So my take is that it should be safe to do..

@svezfaz svezfaz force-pushed the 182-FTP-toPath-sink branch 2 times, most recently from 2e28cd6 to 4dbe282 Compare February 21, 2017 19:05
Copy link
Member

@johanandren johanandren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@patriknw patriknw self-assigned this Mar 20, 2017
Copy link
Member

@patriknw patriknw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -97,4 +99,47 @@ trait CommonFtpSourceSpec extends BaseSpec {
}
}

"FtpIOSink" should {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good to keep it simple, and stick to jimfs

@patriknw
Copy link
Member

@svezfaz @juanjovazquez anything more remaining here apart from a rebase?

@svezfaz
Copy link
Contributor Author

svezfaz commented Mar 23, 2017

@patriknw I think this one is ready to go. Further expansions will be handled in future tickets. Thanks for reviewing.

@juanjovazquez
Copy link

@svezfaz @patriknw LGTM

@patriknw
Copy link
Member

thanks, please rebase @svezfaz

@svezfaz svezfaz force-pushed the 182-FTP-toPath-sink branch from 4dbe282 to a265241 Compare March 23, 2017 18:56
@svezfaz
Copy link
Contributor Author

svezfaz commented Mar 23, 2017

@patriknw rebased

@johanandren johanandren merged commit a38453c into akka:master Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants