[jira] Assigned: (AVRO-705) DirectBinaryDecoder not correctly re-initialized with reuse option
[
https://issues.apache.org/jira/browse/AVRO-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. reassigned AVRO-705:
Assignee: Thiruvalluvan M. G.
DirectBinaryDecoder not correctly re-initialized with reuse option
--
Key: AVRO-705
URL: https://issues.apache.org/jira/browse/AVRO-705
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.4.1
Reporter: Gilles Gaillard
Assignee: Thiruvalluvan M. G.
Calling {{DecoderFactory.createBinaryDecoder(InputStream in, BinaryDecoder
reuse)}} with {{reuse}} being a non null {{DirectBinaryDecoder}}, this
{{DirectBinaryDecoder}} is simply reinitialized by a call to
{{DirectBinaryDecoder.init}} which reinitializes the internal {{InputStream}}.
The problem is that the {{byteReader}} attribute of {{DirectBinaryDecoder}}
is not reinitialized and still points to the previously assigned
{{ByteBufferInputStream}}
The following is a proposition of correction at rev 1041110:
{noformat}
private ByteReader byteReader;
DirectBinaryDecoder(InputStream in) {
super();
init(in);
}
@Override
public void init(InputStream in) {
this.in = in;
byteReader = (in instanceof ByteBufferInputStream)
? new ReuseByteReader((ByteBufferInputStream) in)
: new ByteReader();
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-706) Java: Type promotion not succeeding for long - float
[
https://issues.apache.org/jira/browse/AVRO-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-706:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed revision 1041903.
Thanks Doug for reviewing the fix.
Java: Type promotion not succeeding for long - float
-
Key: AVRO-706
URL: https://issues.apache.org/jira/browse/AVRO-706
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.4.1
Reporter: Scott Carey
Assignee: Thiruvalluvan M. G.
Fix For: 1.5.0
Attachments: AVRO-706.patch
A bug reported on the dev email list. I have not confirmed it:
{quote}
Hi,
Avro spec says that writer schema's long can be promoted to reader
schema's float or double. In my test, I'm getting ErrorAction from
ResolvingGrammarGenerator.generate() when writer schema is long and
reader schema expects float. Looking at the source code, when reader
and writer type are not the same, the switch(readerType) only handles
Long, Double and Union, not Float. This is the reason I'm getting Found
Long, expecting Float error.
Best regards,
Xiaolu
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-700) Change C++ build system to C++
[ https://issues.apache.org/jira/browse/AVRO-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvalluvan M. G. updated AVRO-700: - Attachment: ignored_files apply-patch.sh AVRO-700.patch A much cleaner version all files produced during make are put into build directory leaving lang/c++ clean. Please download ignored_files, apply_patch.sh and AVRO-700.patch into the top level Avro source directory. From within that directory, issue: sh ./apply_patch.sh patch -p0 AVRO-700.patch Change C++ build system to C++ -- Key: AVRO-700 URL: https://issues.apache.org/jira/browse/AVRO-700 Project: Avro Issue Type: Improvement Components: c++ Affects Versions: 1.5.0 Reporter: Thiruvalluvan M. G. Assignee: Thiruvalluvan M. G. Fix For: 1.5.0 Attachments: apply-patch.sh, apply-patch.sh, AVRO-700.patch, AVRO-700.patch, ignored_files If we move from the current automake to CMake, build becomes portable across multiple platforms. Prior to this patch, Avro C++ was building on Cygwin but was crashing. I've tested this on Ubuntu 10.04 and Cygwin. There are problems making it work with Visual Studio 2008 Express, not because of CMake, but because the current build procedure needs Flex, Bison and python. Visual Studio seems to have trouble with these three. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-705) DirectBinaryDecoder not correctly re-initialized with reuse option
[
https://issues.apache.org/jira/browse/AVRO-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-705:
-
Attachment: AVRO-705.patch
Good catch!
Added a test that catches the bug and fixed the bug as well.
DirectBinaryDecoder not correctly re-initialized with reuse option
--
Key: AVRO-705
URL: https://issues.apache.org/jira/browse/AVRO-705
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.4.1
Reporter: Gilles Gaillard
Assignee: Thiruvalluvan M. G.
Attachments: AVRO-705.patch
Calling {{DecoderFactory.createBinaryDecoder(InputStream in, BinaryDecoder
reuse)}} with {{reuse}} being a non null {{DirectBinaryDecoder}}, this
{{DirectBinaryDecoder}} is simply reinitialized by a call to
{{DirectBinaryDecoder.init}} which reinitializes the internal {{InputStream}}.
The problem is that the {{byteReader}} attribute of {{DirectBinaryDecoder}}
is not reinitialized and still points to the previously assigned
{{ByteBufferInputStream}}
The following is a proposition of correction at rev 1041110:
{noformat}
private ByteReader byteReader;
DirectBinaryDecoder(InputStream in) {
super();
init(in);
}
@Override
public void init(InputStream in) {
this.in = in;
byteReader = (in instanceof ByteBufferInputStream)
? new ReuseByteReader((ByteBufferInputStream) in)
: new ByteReader();
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-705) DirectBinaryDecoder not correctly re-initialized with reuse option
[
https://issues.apache.org/jira/browse/AVRO-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiruvalluvan M. G. updated AVRO-705:
-
Status: Patch Available (was: Open)
DirectBinaryDecoder not correctly re-initialized with reuse option
--
Key: AVRO-705
URL: https://issues.apache.org/jira/browse/AVRO-705
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.4.1
Reporter: Gilles Gaillard
Assignee: Thiruvalluvan M. G.
Attachments: AVRO-705.patch
Calling {{DecoderFactory.createBinaryDecoder(InputStream in, BinaryDecoder
reuse)}} with {{reuse}} being a non null {{DirectBinaryDecoder}}, this
{{DirectBinaryDecoder}} is simply reinitialized by a call to
{{DirectBinaryDecoder.init}} which reinitializes the internal {{InputStream}}.
The problem is that the {{byteReader}} attribute of {{DirectBinaryDecoder}}
is not reinitialized and still points to the previously assigned
{{ByteBufferInputStream}}
The following is a proposition of correction at rev 1041110:
{noformat}
private ByteReader byteReader;
DirectBinaryDecoder(InputStream in) {
super();
init(in);
}
@Override
public void init(InputStream in) {
this.in = in;
byteReader = (in instanceof ByteBufferInputStream)
? new ReuseByteReader((ByteBufferInputStream) in)
: new ByteReader();
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-700) Change C++ build system to CMake
[ https://issues.apache.org/jira/browse/AVRO-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvalluvan M. G. updated AVRO-700: - Summary: Change C++ build system to CMake (was: Change C++ build system to C++) Change C++ build system to CMake Key: AVRO-700 URL: https://issues.apache.org/jira/browse/AVRO-700 Project: Avro Issue Type: Improvement Components: c++ Affects Versions: 1.5.0 Reporter: Thiruvalluvan M. G. Assignee: Thiruvalluvan M. G. Fix For: 1.5.0 Attachments: apply-patch.sh, apply-patch.sh, AVRO-700.patch, AVRO-700.patch, ignored_files If we move from the current automake to CMake, build becomes portable across multiple platforms. Prior to this patch, Avro C++ was building on Cygwin but was crashing. I've tested this on Ubuntu 10.04 and Cygwin. There are problems making it work with Visual Studio 2008 Express, not because of CMake, but because the current build procedure needs Flex, Bison and python. Visual Studio seems to have trouble with these three. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-700) Change C++ build system to CMake
[ https://issues.apache.org/jira/browse/AVRO-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvalluvan M. G. updated AVRO-700: - Attachment: (was: AVRO-700.patch) Change C++ build system to CMake Key: AVRO-700 URL: https://issues.apache.org/jira/browse/AVRO-700 Project: Avro Issue Type: Improvement Components: c++ Affects Versions: 1.5.0 Reporter: Thiruvalluvan M. G. Assignee: Thiruvalluvan M. G. Fix For: 1.5.0 Attachments: apply-patch.sh, apply-patch.sh, AVRO-700.patch, AVRO-700.patch, ignored_files If we move from the current automake to CMake, build becomes portable across multiple platforms. Prior to this patch, Avro C++ was building on Cygwin but was crashing. I've tested this on Ubuntu 10.04 and Cygwin. There are problems making it work with Visual Studio 2008 Express, not because of CMake, but because the current build procedure needs Flex, Bison and python. Visual Studio seems to have trouble with these three. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-700) Change C++ build system to CMake
[ https://issues.apache.org/jira/browse/AVRO-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvalluvan M. G. updated AVRO-700: - Attachment: AVRO-700.patch The test paths were wrong in build.sh Change C++ build system to CMake Key: AVRO-700 URL: https://issues.apache.org/jira/browse/AVRO-700 Project: Avro Issue Type: Improvement Components: c++ Affects Versions: 1.5.0 Reporter: Thiruvalluvan M. G. Assignee: Thiruvalluvan M. G. Fix For: 1.5.0 Attachments: apply-patch.sh, apply-patch.sh, AVRO-700.patch, AVRO-700.patch, ignored_files If we move from the current automake to CMake, build becomes portable across multiple platforms. Prior to this patch, Avro C++ was building on Cygwin but was crashing. I've tested this on Ubuntu 10.04 and Cygwin. There are problems making it work with Visual Studio 2008 Express, not because of CMake, but because the current build procedure needs Flex, Bison and python. Visual Studio seems to have trouble with these three. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AVRO-704) SockServer concurrency issues
[ https://issues.apache.org/jira/browse/AVRO-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doug Cutting updated AVRO-704: -- Attachment: AVRO-704.patch Here's a patch that fixes this. The bugfix is in SocketTransceiver.java. The other changes were to make this easier to debug, including adding support for socket clients to the rpcsend tool. SockServer concurrency issues - Key: AVRO-704 URL: https://issues.apache.org/jira/browse/AVRO-704 Project: Avro Issue Type: Bug Components: java Affects Versions: 1.4.1 Reporter: Eric Evans Fix For: 1.5.0 Attachments: AVRO-704.patch The SocketServer does not shutdown threads when clients disconnect. Also, these idle threads seem to chew up a _lot_ of CPU. A simple echo server will peg the processor on my dev machine after accumulating just 2 or 3 of these threads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AVRO-707) promote Sasl-based RPC
promote Sasl-based RPC -- Key: AVRO-707 URL: https://issues.apache.org/jira/browse/AVRO-707 Project: Avro Issue Type: Improvement Components: java Reporter: Doug Cutting Fix For: 1.5.0 SaslSocketTransceiver and SaslSocketServer should be preferred to SocketTransceiver and SocketServer. The former are more optimized and offer the option of security. The latter should be deprecated to discourage a proliferation of implementations. We should also add Transceiver and Server factory methods that accept a URI. For http: URIs these should use HttpTransceiver and HttpServer. For avro: URIs these should use SaslSocketTransceiver and SaslSocketServer. The rpcsend and rpcrecieve tools should use these factories. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-704) SockServer concurrency issues
[ https://issues.apache.org/jira/browse/AVRO-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966769#action_12966769 ] Doug Cutting commented on AVRO-704: --- I'll move all but the fix to AVRO-707. Eric, note also that I think SaslSocketServer doesn't set no-delay. That may account for the performance issues you reported with it on IRC today. SockServer concurrency issues - Key: AVRO-704 URL: https://issues.apache.org/jira/browse/AVRO-704 Project: Avro Issue Type: Bug Components: java Affects Versions: 1.4.1 Reporter: Eric Evans Assignee: Doug Cutting Fix For: 1.5.0 Attachments: AVRO-704.patch The SocketServer does not shutdown threads when clients disconnect. Also, these idle threads seem to chew up a _lot_ of CPU. A simple echo server will peg the processor on my dev machine after accumulating just 2 or 3 of these threads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-703) socket transport for Python
[ https://issues.apache.org/jira/browse/AVRO-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966771#action_12966771 ] Doug Cutting commented on AVRO-703: --- This should probably implement anonymous SASL, as described in: http://avro.apache.org/docs/current/sasl.html#anonymous That way we can have a single socket-based client-server format that can gracefully provide authentication and encryption. socket transport for Python --- Key: AVRO-703 URL: https://issues.apache.org/jira/browse/AVRO-703 Project: Avro Issue Type: New Feature Components: python Affects Versions: 1.4.1 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Attachments: 0001-python-socket-transceiver.patch Python users need a more performant alternative to HTTP transport. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-703) socket transport for Python
[ https://issues.apache.org/jira/browse/AVRO-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966777#action_12966777 ] Eric Evans commented on AVRO-703: - make sense to me. socket transport for Python --- Key: AVRO-703 URL: https://issues.apache.org/jira/browse/AVRO-703 Project: Avro Issue Type: New Feature Components: python Affects Versions: 1.4.1 Reporter: Eric Evans Assignee: Eric Evans Priority: Minor Attachments: 0001-python-socket-transceiver.patch Python users need a more performant alternative to HTTP transport. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-704) SockServer concurrency issues
[ https://issues.apache.org/jira/browse/AVRO-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966778#action_12966778 ] Eric Evans commented on AVRO-704: - It gets set on the client and I think it only needs to be set on one end(?) At any rate, I tried setting nodelay in the other constructor and it didn't effect the results. SockServer concurrency issues - Key: AVRO-704 URL: https://issues.apache.org/jira/browse/AVRO-704 Project: Avro Issue Type: Bug Components: java Affects Versions: 1.4.1 Reporter: Eric Evans Assignee: Doug Cutting Fix For: 1.5.0 Attachments: AVRO-704.patch The SocketServer does not shutdown threads when clients disconnect. Also, these idle threads seem to chew up a _lot_ of CPU. A simple echo server will peg the processor on my dev machine after accumulating just 2 or 3 of these threads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
