Uploaded image for project: 'CDAP'
  1. CDAP
  2. CDAP-3962

CDAP under Windows doesn't seem to support network drives

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.0
    • Fix Version/s: 3.5.0
    • Component/s: CDAP
    • Labels:
      None
    • Rank:
      1|hzz1lj:

      Description

      This is a bit of an odd issue, and is filed more so that anyone who comes across it can work around the problem.

      One way of testing a Windows installation of CDAP is to use a virtual machine, and one example is Parallels on the Mac, with Windows running in a virtual machine. The Mac drives can be made visible to the PC as "network drives".

      However, though CDAP can be started, attempts to deploy an app see errors, such as these:

      Standalone CDAP started successfully.
      Connect to the CDAP UI at http://localhost:9999
      -chgrp: '\Everyone' does not match expected pattern for group
      Usage: hadoop fs [generic options] -chgrp [-R] GROUP PATH...
      2015-10-08 15:09:48,978 - ERROR [executor-19:c.c.c.c.HttpExceptionHandler@56] - Unexpected error: request=POST /v3/namespaces/default/apps/CountRandom/flows/CountRandom/start user=<null>:
      java.lang.IllegalArgumentException: Newer program update time than the specification update time. Application must be redeployed
      	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:92) ~[co.cask.cdap.cdap-cli-3.2.0.jar:na]
      	at co.cask.cdap.internal.app.store.DefaultStore.loadProgram(DefaultStore.java:191) ~[co.cask.cdap.cdap-app-fabric-3.2.0.jar:na]
      	at co.cask.cdap.internal.app.services.ProgramLifecycleService.getProgram(ProgramLifecycleService.java:110) ~[co.cask.cdap.cdap-app-fabric-3.2.0.jar:na]
      	at co.cask.cdap.internal.app.services.ProgramLifecycleService.start(ProgramLifecycleService.java:131) ~[co.cask.cdap.cdap-app-fabric-3.2.0.jar:na]
      	at co.cask.cdap.gateway.handlers.ProgramLifecycleHttpHandler.start(ProgramLifecycleHttpHandler.java:1294) ~[co.cask.cdap.cdap-app-fabric-3.2.0.jar:na]
      	at co.cask.cdap.gateway.handlers.ProgramLifecycleHttpHandler.startStopProgram(ProgramLifecycleHttpHandler.java:1263) ~[co.cask.cdap.cdap-app-fabric-3.2.0.jar:na]
      	at co.cask.cdap.gateway.handlers.ProgramLifecycleHttpHandler.performAction(ProgramLifecycleHttpHandler.java:352) ~[co.cask.cdap.cdap-app-fabric-3.2.0.jar:na]
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_79]
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_79]
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_79]
      	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_79]
      	at co.cask.http.HttpMethodInfo.invoke(HttpMethodInfo.java:79) ~[co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at co.cask.http.HttpDispatcher.messageReceived(HttpDispatcher.java:41) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:314) [co.cask.cdap.cdap-explore-jdbc-3.2.0.jar:na]
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
      	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
      

      This suggests that the timestamps for the files on the Mac are being interpreted incorrectly somehow.

      The workaround was to move the entire SDK to the "C:" drive of the Windows virtual machine. At that point, CAP started and apps (CountRandom) behaved as expected.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                terence Terence Yim
                Reporter:
                John John Jackson
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: