[
https://issues.apache.org/jira/browse/AVRO-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965000#action_12965000
]
Scott Carey commented on AVRO-647:
----------------------------------
Re: Failing tests.
Mac OSX SnowLeopard (latest OSX version).
I have test failures as described at :
https://issues.apache.org/jira/browse/AVRO-668?focusedCommentId=12910239&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12910239
There is a JIRA for one of them from a while back but its not what is blocking
me now:
https://issues.apache.org/jira/browse/AVRO-644
We can work on that in another JIRA but from what I recall, we'll probably have
to cooperate via irc. For the most part it boils down to ports and/or files
not being there when the tests think they should be.
{noformat}
[junit] Running org.apache.avro.TestProtocolGenericMeta
[junit] Tests run: 6, Failures: 0, Errors: 5, Time elapsed: 0.018 sec
[junit] Error:
[junit] 6057 [main] INFO org.apache.avro.ipc.SocketTransceiver - open to
0.0.0.0/0.0.0.0:61911
[junit] 6058 [Connection to /10.0.0.231:61914] INFO
org.apache.avro.ipc.SocketTransceiver - open to /10.0.0.231:61914
[junit] 6061 [Connection to /10.0.0.231:61914] INFO
org.apache.avro.TestProtocolGeneric - hello: bob
[junit] 6062 [main] INFO org.apache.avro.ipc.SocketTransceiver - closing to
0.0.0.0/0.0.0.0:61911
[junit]
[junit] TEST org.apache.avro.TestProtocolGenericMeta FAILED
{noformat}
and more of a problem is that many tests related to ipc hang forever.
At this time, I have this running indefinitely:
{noformat}
[junit] Running org.apache.avro.TestProtocolHttp
[junit] 6062 [main] INFO org.apache.avro.ipc.SocketTransceiver - closing to
0.0.0.0/0.0.0.0:61911
[junit] 6072 [main] INFO org.apache.avro.ipc.DatagramTransceiver - sent to
/127.0.0.1:11543
{noformat}
in the stack trace:
{noformat}
"main" prio=5 tid=102800800 nid=0x100501000 runnable [1004ff000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.DatagramChannelImpl.receive0(Native Method)
at
sun.nio.ch.DatagramChannelImpl.receiveIntoNativeBuffer(DatagramChannelImpl.java:202)
at sun.nio.ch.DatagramChannelImpl.receive(DatagramChannelImpl.java:188)
at sun.nio.ch.DatagramChannelImpl.receive(DatagramChannelImpl.java:132)
- locked <10860b878> (a java.lang.Object)
at
org.apache.avro.ipc.DatagramTransceiver.readBuffers(DatagramTransceiver.java:56)
- locked <10860b6c8> (a org.apache.avro.ipc.DatagramTransceiver)
at org.apache.avro.ipc.Transceiver.transceive(Transceiver.java:39)
- locked <10860b6c8> (a org.apache.avro.ipc.DatagramTransceiver)
at org.apache.avro.ipc.Requestor.request(Requestor.java:123)
- locked <10860f9b0> (a org.apache.avro.specific.SpecificRequestor)
at
org.apache.avro.specific.SpecificRequestor.invoke(SpecificRequestor.java:52)
at $Proxy12.echo(Unknown Source)
at
org.apache.avro.TestProtocolSpecific.testEcho(TestProtocolSpecific.java:108)
{noformat}
I can spin up a linux VM to test before committing. It would definitely be
good if we figured out what is going on however -- i'm probably not the only
Mac user with this problem.
> Break avro.jar into avro.jar, avro-dev.jar and avro-hadoop.jar
> --------------------------------------------------------------
>
> Key: AVRO-647
> URL: https://issues.apache.org/jira/browse/AVRO-647
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Scott Carey
> Assignee: Scott Carey
> Fix For: 1.5.0
>
> Attachments: AVRO-647.patch, migrateAvro.sh
>
>
> Our dependencies are starting to get a little complicated on the Java side.
> I propose we build two (possibly more) jars related to our major dependencies
> and functions.
> 1. avro.jar (or perhaps avro-core.jar)
> This contains all of the core avro functionality for _using_ avro as a
> library. This excludes the specific compiler, avro idl, and other build-time
> or development tools, as well as avro packages for third party integration
> such as hadoop. This jar should then have a minimal set of dependencies
> (jackson, jetty, SLF4J ?).
> 2. avro-dev.jar
> This would contain compilers, idl, development tools, etc. Most applications
> will not need this, but build systems and developers will.
> 3. avro-hadoop.jar
> This would contain the hadoop API and possibly pig/hive/whatever related to
> that. This makes it easier for pig/hive/hadoop to consume avro-core without
> circular dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
