[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797003#action_12797003
]
Matt Massie commented on AVRO-163:
--
bq. I think if someone was writing a test for a specific
[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796956#action_12796956
]
Philip Zeyliger commented on AVRO-163:
--
I think if someone was writing a test for a spec
Sounds good. thanks.
-ryan
On Tue, Jan 5, 2010 at 1:54 PM, Doug Cutting wrote:
> This is under https://issues.apache.org/jira/browse/AVRO-163.
>
> I've started working on this today.
>
> For ruby, mostly just organize things within src/ruby as you would in a
> standalone ruby project. The prima
[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796930#action_12796930
]
Doug Cutting commented on AVRO-163:
---
> Do we need examples of serialized data?
The interop
[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796926#action_12796926
]
Jeff Hammerbacher commented on AVRO-163:
Do we need examples of serialized data? I re
[
https://issues.apache.org/jira/browse/AVRO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated AVRO-291:
Attachment: 0001-enable-SO_NODELAY-on-SocketTransceiver.patch
Here is what I used.
> SocketServer does not s
[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-163:
--
Assignee: Doug Cutting (was: Matt Massie)
Affects Version/s: (was: 1.2.0)
This is under https://issues.apache.org/jira/browse/AVRO-163.
I've started working on this today.
For ruby, mostly just organize things within src/ruby as you would in a
standalone ruby project. The primary exceptions are that you'll get
test data from src/share/test and post some built artif
I vaguely remember someone mentioning reorganizing the avro repository
to group code and tests by language. Is this a possibility? We're
working on a new ruby implementation on githhub
[http://github.com/jmhodges/avro/tree/ruby] and its a bit difficult to
use most ruby tools when the tests and code
[
https://issues.apache.org/jira/browse/AVRO-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796855#action_12796855
]
Philip Zeyliger commented on AVRO-285:
--
This would work. I think it would be a bit more
On Tue, Jan 5, 2010 at 11:56 AM, Doug Cutting wrote:
> Philip Zeyliger wrote:
>
>> Thinking out loud, the handshake could negotiate not just the schema for
>> the
>> protocol, but also the schema for the RPC metadata.
>>
>
> So we'd send a hash of the handshake's schema too? I think sending a ma
Philip Zeyliger wrote:
Thinking out loud, the handshake could negotiate not just the schema for the
protocol, but also the schema for the RPC metadata.
So we'd send a hash of the handshake's schema too? I think sending a
magic number is equivalent and simpler.
Is the call-id value arbitrar
Cool. This seems appropriate to include in the spec. I'll make up a
small patch and submit it.
--
Jeff
On Tue, Jan 5, 2010 at 11:41 AM, Doug Cutting wrote:
> Ryan King wrote:
>>
>> I'm tempted to just generate 16 random bytes for the ruby
>> implementation. Will that be sufficient?
>
> A good ran
Ryan King wrote:
I'm tempted to just generate 16 random bytes for the ruby
implementation. Will that be sufficient?
A good random number generator should be sufficient.
Doug
I'm a little wary of sending the string "Request-Id" with every RPC message.
Maybe it's not a big deal, though. How many bytes does it take to send and
receive a null?
Thinking out loud, the handshake could negotiate not just the schema for the
protocol, but also the schema for the RPC metadata.
Is there a preferred method? The java implementation uses the UID from
RMI, the python implementation generates a random uuid. I haven't
looked at the others yet.
I'm tempted to just generate 16 random bytes for the ruby
implementation. Will that be sufficient?
-ryan
[
https://issues.apache.org/jira/browse/AVRO-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-271:
--
Resolution: Fixed
Fix Version/s: 1.3.0
Status: Resolved (was: Patch Available)
I just
[
https://issues.apache.org/jira/browse/AVRO-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-264:
--
Resolution: Fixed
Fix Version/s: 1.3.0
Status: Resolved (was: Patch Available)
I just
[
https://issues.apache.org/jira/browse/AVRO-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting resolved AVRO-290.
---
Resolution: Duplicate
Duplicate of AVRO-291.
> SocketServer doesn'
> ---
>
>
[
https://issues.apache.org/jira/browse/AVRO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796794#action_12796794
]
Doug Cutting commented on AVRO-291:
---
Eric, can you please attach a patch with the changes y
[
https://issues.apache.org/jira/browse/AVRO-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting reopened AVRO-290:
---
Should have been resolved as "duplicate", not "fixed".
> SocketServer doesn'
> ---
>
>
Hadoop's existing RPC transport supports multiplexing. If a client
issues a request to a server, then, before a response has been
generated, the client (in a separate thread, typically) issues a second
request, that second request can be sent and its response can be
received before the first resp
[
https://issues.apache.org/jira/browse/AVRO-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans resolved AVRO-290.
-
Resolution: Fixed
Sorry. Browser Fail.
> SocketServer doesn'
> ---
>
> Key
23 matches
Mail list logo
