Namespaces are a datastore specific concept. It caused trouble in this
instance because the local mock of GCS uses the datastore for its metadata.
Real GCS does not depend on datastore, so this problem will not occur with
deployed code.
On Fri, Dec 13, 2013 at 6:05 AM, Troy High <troy.h...@metablock.com> wrote:
> I was having the exact same problem with namespaces and the local dev
> server not honoring them for some entries. I applied the same workaround as
> Ken and am able to retrieve files programmatically.
>
> So is this a bug in the Dev server implementation or does this mean cloud
> storage does not officially support namespaces? I haven't pushed this code
> to the google servers yet so I am not sure if I would encounter the same
> issue without the workaround.
>
> Thanks,
> Troy
>
>
> On Friday, November 22, 2013 12:40:05 PM UTC-5, k...@form-runner.comwrote:
>>
>> Nailed the culprit!
>>> We make extensive use of namespaces, and in my original post, there
>>> turns out to be an unfortunate interaction between namespaces and the GCS
>>> client API.
>>>
>>> Down in my original post, where I laid out all the data I could find in
>>> the Development Console, you will see that there are entries in the empty
>>> namespace and a different namespace:
>>>
>>> In __GsFileInfo__ (in the empty Namespace)
>>> ….blah … blah
>>>
>>> In Namespace 5629499534213120 (where everything ran):
>>> In _ah_FakeCloudStorate_formrunnerbucket-r7yh23nb2:
>>> …. blah…. blah
>>>
>>> The code for writing into GCS ran in namespace 5629499534213120, but it
>>> wrote part of it's data into the empty namespace.
>>>
>>> The (successful) experiment was to ensure that all the GCS API code
>>> (read and write) runs in the empty namespace, conceptually thus:
>>>
>>> private byte[] readFromFile(GcsFilename fullGcsFilename) throws
>>> IOException
>>> {
>>> String in_ns = NamespaceManager.get();
>>> NamespaceManager.set(null);
>>> int fileSize = (int) gcsService.getMetadata(
>>> fullGcsFilename).getLength();
>>> ByteBuffer result = ByteBuffer.allocate(fileSize);
>>> GcsInputChannel readChannel = gcsService.openReadChannel(fullGcsFilename,
>>> 0);
>>> try {
>>> readChannel.read(result);
>>> } finally {
>>> readChannel.close();
>>> }
>>> byte[] toreturn=result.array();
>>> NamespaceManager.set(in_ns);
>>> return toreturn;
>>> }
>>>
>>> Now the FileNotFound does not occur, and I do get (some) bytes back,
>>> about 1/10 of the 1.2MB. Presumably when I switch to ObjectStreaming, I'll
>>> get all.
>>> Cheers,
>>> --Ken
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.
