Re: Cannot create subscription because pipeline option 'project' not specified

2018-07-26 Thread Andrew Pilloud
Your second stacktrace isn't going through SQL. It looks like you are using the normal test path there. Have you tried setting in both places? On Thu, Jul 26, 2018, 5:48 PM Rui Wang wrote: > Ah, SET project = apache-beam-testing; gives the following exception: > > io.grpc.StatusRuntimeException

Re: Cannot create subscription because pipeline option 'project' not specified

2018-07-26 Thread Rui Wang
Ah, SET project = apache-beam-testing; gives the following exception: io.grpc.StatusRuntimeException: PERMISSION_DENIED: User not authorized to perform this action. at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:222) at io.grpc.stub.ClientCalls.getUnchecked

Re: Cannot create subscription because pipeline option 'project' not specified

2018-07-26 Thread Andrew Pilloud
Beam SQL CLI does not accept beamTestPipelineOptions. Also, gradle is invoking your test not the Beam SQL CLI. You'll need to set the options in your integration test by executing 'SET project = ...' in the Beam SQL connection you've launched for test. Andrew On Thu, Jul 26, 2018 at 3:06 PM Rui W

Re: Cannot create subscription because pipeline option 'project' not specified

2018-07-26 Thread Rui Wang
The code path of reading pubsub through BeamSQL goes through this line of code: PubsubIO.Read read = PubsubIO.readMessagesWithAttributes().fromTopic(getTopic()); -Rui On Thu, Jul 26, 2018 at 2:58 PM Rui Wang wrote: > Hi Community, > > I am facing a runtime exception when I try to read from pub

Cannot create subscription because pipeline option 'project' not specified

2018-07-26 Thread Rui Wang
Hi Community, I am facing a runtime exception when I try to read from pubsub by Beam SQL in JUnit tests (PR: https://github.com/apache/beam/pull/6006). The exception is "Cannot create subscription because pipeline option 'project' not specified". Based on existing JUnit tests which also read from

Re: [PROPOSAL] Prepare Beam 2.6.0 release

2018-07-26 Thread Pablo Estrada
Hello everyone, I wanted to do an update on the state of the release, as there haven't been news on this for a while. We have found a few issues that broke postcommits a few weeks back, but we hadn't noticed. Some people are tacking these to try to stabilize the release branch[1]. In the meantime,

Re: FileBasedSink.WriteOperation copy instead of move?

2018-07-26 Thread Chamikara Jayalath
Yeah, please file a JIRA. - Cham On Thu, Jul 26, 2018 at 11:33 AM Jozef Vilcek wrote: > Yes, rename can be tricky with cross-directory. This is related > https://issues.apache.org/jira/browse/BEAM-4861 > I guess I can file a JIRA for this, right? > > On Thu, Jul 26, 2018 at 7:31 PM Chamikara Ja

Re: FileBasedSink.WriteOperation copy instead of move?

2018-07-26 Thread Jozef Vilcek
Yes, rename can be tricky with cross-directory. This is related https://issues.apache.org/jira/browse/BEAM-4861 I guess I can file a JIRA for this, right? On Thu, Jul 26, 2018 at 7:31 PM Chamikara Jayalath wrote: > Also, we'll have to use StandardMoveOptions.IGNORE_MISSING_FILES for > supporting

Re: FileBasedSink.WriteOperation copy instead of move?

2018-07-26 Thread Chamikara Jayalath
Also, we'll have to use StandardMoveOptions.IGNORE_MISSING_FILES for supporting failures of the rename step. I think this is a good change to do if the change significantly improves the performance of some of the FileSystems (note that some FileSystems, for example GCS, implement rename in the form

Re: FileBasedSink.WriteOperation copy instead of move?

2018-07-26 Thread Reuven Lax
We might be able to replace this with Filesystem.rename(). One thing to keep in mind - the destination files might be in a different directory, so we would need to make sure that all Filesystems support cross-directory rename. On Thu, Jul 26, 2018 at 9:58 AM Lukasz Cwik wrote: > +dev > > On Thu,

Re: FileBasedSink.WriteOperation copy instead of move?

2018-07-26 Thread Lukasz Cwik
+dev On Thu, Jul 26, 2018 at 2:40 AM Jozef Vilcek wrote: > Hello, > > just came across FileBasedSink.WriteOperation class which does have > moveToOutput() method. Implementation does a Filesystem.copy() instead of > "move". With large files I find it quote no efficient if underlying FS > support