Hi,
I'm using Protocol Buffers in an open source project[1]. I have a tree
structure in memory which represents some directories and files.
This structure must be persisted, so I've defined some protocol
messages[2] to do that.
The persist routine[3] will run through the tree structure to build
Hey,
I'm using ACE library for C++ and it's reactor pattern for handling
asynchronous read from / write to sockets.
I'm trying to integrate Protocol buffers into my solution in order to
exchange data with another process developed in Java.
The way asynchronous work, forces me to know in advance
Protobufs are pretty much designed to be read all at once. The normal
thing would be to define a stream format that prefixes the serialized
protobufs with their length and buffer the data until a whole protobuf
has been read.
In other words: you should not describe the whole stream as a single
Hey,
The protocol we've defined for this kind of solution is to send a
fixed 4 byte unsigned interger that represents the
following PB message length, read the PB message and wait again for
the size.
So in this case, what is the best method to use PB?
Should i use SerializeToArray and
Thanks,
It's working fine now!
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more
Thanks for the suggestion.
Do you think that using std::iostream in the following scenario would
work / be a good choice?
1. read message_length
2. buffer message_length bytes into iostream variable.
3. when all data is received, use IstreamInputStream to wrap the
iostream and have it parsed
Gilad Ben-Ami wrote:
Do you think that using std::iostream in the following scenario would
work / be a good choice?
1. read message_length
2. buffer message_length bytes into iostream variable.
3. when all data is received, use IstreamInputStream to wrap the
iostream and have it parsed with
Are you sure the leak is due to persistCacheToFile()? It looks like your
FileManager::loadCacheFromFile() method is leaking the protocol buffer when
you are reading the cache back in.
If that's not the case, can you send a small reproduction of the problem?
On Tue, Nov 24, 2009 at 2:03 AM, Greg
Jason Hsueh wrote:
Are you sure the leak is due to persistCacheToFile()?
Does it due to memory fragmentation ? It's very strange because this
method 'FileManager::persistCacheToFile()'[3] should delete all its
memory when it returns. Should I use a other memory allocater like
tcmalloc ?
I
[...@lothlorien ~]$ java -version
java version 1.6.0_0
OpenJDK Runtime Environment (IcedTea6 1.6) (fedora-21.b16.fc10-i386)
OpenJDK Server VM (build 14.0-b16, mixed mode)
[...@lothlorien ~]$
On Nov 20, 6:01 pm, Kenton Varda ken...@google.com wrote:
What version of Java are you using? It looks
When I link protobuf library on linux suse to empty program valgrind
starts to complain about:
==26306== Invalid free() / delete / delete[]
==26306==at 0x4A1F99E: free (vg_replace_malloc.c:323)
==26306==by 0x6467D1A: free_mem (in /lib64/libc-2.4.so)
==26306==by 0x6467991:
I can't tell anything from that stack trace, sorry.
On Tue, Nov 24, 2009 at 10:10 AM, Vlad vladimir.sakha...@gmail.com wrote:
When I link protobuf library on linux suse to empty program valgrind
starts to complain about:
==26306== Invalid free() / delete / delete[]
==26306==at
Yes, use std::string. The only potential problem is if your messages are
very large -- allocating large contiguous blocks of memory (as std::string
does) could lead to memory fragmentation. But for small and medium-sized
messages, there's no reason not to use std::string as the buffer. Parsing
Hello all;
I need to serialize a protobuf message to a string so that it can be
passed outside my program. The below fails, I'm guessing due to UTF8
encoding issues:
byte[] arr = msg.toByteArray();
String str = new String(arr);
// ... pass str around ...
MsgType msg2 =
Strings contain text, not arbitrary bytes. Encoded protocol buffers are
arbitrary bytes, not text. So, they aren't compatible. You would need to
do something like base-64 encode the data in order to put it in a String.
On Tue, Nov 24, 2009 at 3:16 PM, Will Morton will.mor...@gmail.com wrote:
2009/11/25 Adam Vartanian flo...@google.com:
What am I doing wrong? What's the best way to do java string
serialization of protobuf messages?
If you absolutely have to pass things around as a String, you're going
to need to do so in some kind of encoding that supports arbitrary
data. For
You can use TextFormat but it is probably *less* efficient than base64.
On Tue, Nov 24, 2009 at 4:14 PM, Will Morton will.mor...@gmail.com wrote:
2009/11/25 Adam Vartanian flo...@google.com:
What am I doing wrong? What's the best way to do java string
serialization of protobuf messages?
What am I doing wrong? What's the best way to do java string
serialization of protobuf messages?
The native wire format of protocol buffers is just a sequence of
bytes, so it can contain values that are invalid UTF-8 (or any
encoding that has invalid byte sequences). Trying to pack that into
I guess it's technically the case that a packed field always has non-zero
size, but maybe we should initialize the cached sizes to -1 anyway to make
it more clear when they haven't been initialized?
On Tue, Nov 24, 2009 at 7:04 PM, jas...@google.com wrote:
Reviewers: kenton,
Description:
Fix
On Tue, Nov 24, 2009 at 7:40 PM, Kenton Varda ken...@google.com wrote:
I guess it's technically the case that a packed field always has non-zero
size, but maybe we should initialize the cached sizes to -1 anyway to make
it more clear when they haven't been initialized?
That was a confusing
On Tue, Nov 24, 2009 at 6:45 PM, Alex Antonov a...@antonov.ws wrote:
Rewriting the protocol compiler to use some sort of template system is
not
something we really have resources for. That said, the plugins thing I'm
working on may be useful to similar ends.
Oh, the plugins stuff sounds
21 matches
Mail list logo
