[jira] [Commented] (AVRO-2766) [C++] Compilation failure size_t

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108857#comment-17108857
 ] 

Hudson commented on AVRO-2766:
--

SUCCESS: Integrated in Jenkins build AvroJava #874 (See 
[https://builds.apache.org/job/AvroJava/874/])
AVRO-2766: Fix compilation error: 'size_t' does not name a type (dan: 
[https://github.com/apache/avro/commit/2b398cf179330ef545f2cae0daecd86a4aa3ac89])
* (edit) lang/c++/api/Zigzag.hh


> [C++] Compilation failure size_t
> 
>
> Key: AVRO-2766
> URL: https://issues.apache.org/jira/browse/AVRO-2766
> Project: Apache Avro
>  Issue Type: Bug
>  Components: build, c++
>Affects Versions: 1.9.2
>Reporter: Laurent Stacul
>Priority: Major
>
> With the following system:
> {code:java}
> $ uname -a
> Linux edf2927682ca 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 10.0.1 20200220 (experimental){code}
>  
> I received the compilation error:
> {code:java}
> g++  -DAVRO_SOURCE 
> -I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api
>  
> -I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/build
>  
> -I/home/docker/development/opensource-pack-builder/components/avro/DEPS/osp/Boost/latest/osp/include
>   -DNDEBUG -O3 -std=gnu++2a -fno-working-directory -ggdb3 -flto 
> -ffat-lto-objects -fuse-linker-plugin -Wall -O3 -DNDEBUG   -std=c++11 -fPIC 
> -o CMakeFiles/avrocpp_s.dir/impl/Zigzag.cc.o -c 
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc
> In file included from 
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc:20:
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:37:11:
>  error: 'size_t' does not name a type
>  37 | AVRO_DECL size_t encodeInt32(int32_t input, std::array 
> &output);
>  | ^~
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:26:1:
>  note: 'size_t' is defined in header ''; did you forget to '#include 
> '?
>  25 | #include "Config.hh"
>  +++ |+#include 
>  26 | /// \file
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
>  error: 'size_t' does not name a type
>  38 | AVRO_DECL size_t encodeInt64(int64_t input, std::array 
> &output);
>  | ^~
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
>  note: 'size_t' is defined in header ''; did you forget to '#include 
> '?{code}
> Regards,
> Laurent
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2668) Build failure without a C++ compiler

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108858#comment-17108858
 ] 

Hudson commented on AVRO-2668:
--

SUCCESS: Integrated in Jenkins build AvroJava #874 (See 
[https://builds.apache.org/job/AvroJava/874/])
AVRO-2668: Build failure without a C++ compiler (dan: 
[https://github.com/apache/avro/commit/414a51fdc1856083bb16851f09a4c61a48796132])
* (edit) lang/c/CMakeLists.txt
* (delete) lang/c/tests/test_cpp.cpp
* (edit) lang/c/tests/CMakeLists.txt


> Build failure without a C++ compiler
> 
>
> Key: AVRO-2668
> URL: https://issues.apache.org/jira/browse/AVRO-2668
> Project: Apache Avro
>  Issue Type: Bug
>  Components: c
>Reporter: Fabrice Fontaine
>Priority: Minor
>
> Build of AvroC fails without a C++ compiler:
> CMake Error at CMakeLists.txt:20 (project):
>  The CMAKE_CXX_COMPILER:
> /home/naourr/work/instance-2/output-1/host/bin/microblazeel-buildroot-linux-uclibc-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> More information on build failure can be found here:
>  - 
> http://autobuild.buildroot.org/results/135e246aa70f28c6b9aea5fd6b0eb9c7b45ebfe7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Jenkins build is back to normal : AvroJava #874

[Apache Jenkins Server]

See 

[jira] [Updated] (AVRO-2837) Java DecimalConversion handling of scale and precision

[Matthew McMahon (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew McMahon updated AVRO-2837:
--
Attachment: AVRO-2837.patch

> Java DecimalConversion handling of scale and precision
> --
>
> Key: AVRO-2837
> URL: https://issues.apache.org/jira/browse/AVRO-2837
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java, logical types
>Affects Versions: 1.8.2, 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2837.patch, AVRO-2837.patch
>
>
> Came across an interesting issue in Avro 1.8.2
> Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
> precision of 28).
> Due to an upstream bug, a value of 1070464558597365250.000 
> (1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
> DecimalConversion attempts to turn it into a Fixed type.
> This should have failed, as it has a precision of 34 and won't fit into the 
> 12 bytes (needs 14). However in 1.8.2 this still writes a value that 
> downstream processing then works out is invalid and errors.
> Basically the top 2 bytes are thrown away.
> This problem is fixed in 1.9.2 due to the change in 
> https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue 
> fails when it attempts to pass an offset of -2 to the System.arraycopy method.
> That seems ok, but is a bit of a red herring to the actual issue, and 
> precision is still not actually being checked.
> Proposing a couple changes to the DecimalConversion:
>  * Check precision set on the decimal logical type. If value has greater 
> precision then error with more informative message
>  * Still check scale and error if value has a greater scale. However if the 
> scale in value is less, than it seems safe to update the scale and pad zero's 
> rather than error
>  * Do this for both Bytes and Fixed types
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2837) Java DecimalConversion handling of scale and precision

[Matthew McMahon (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew McMahon updated AVRO-2837:
--
Issue Type: Bug  (was: Improvement)

> Java DecimalConversion handling of scale and precision
> --
>
> Key: AVRO-2837
> URL: https://issues.apache.org/jira/browse/AVRO-2837
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java, logical types
>Affects Versions: 1.8.2, 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2837.patch
>
>
> Came across an interesting issue in Avro 1.8.2
> Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
> precision of 28).
> Due to an upstream bug, a value of 1070464558597365250.000 
> (1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
> DecimalConversion attempts to turn it into a Fixed type.
> This should have failed, as it has a precision of 34 and won't fit into the 
> 12 bytes (needs 14). However in 1.8.2 this still writes a value that 
> downstream processing then works out is invalid and errors.
> Basically the top 2 bytes are thrown away.
> This problem is fixed in 1.9.2 due to the change in 
> https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue 
> fails when it attempts to pass an offset of -2 to the System.arraycopy method.
> That seems ok, but is a bit of a red herring to the actual issue, and 
> precision is still not actually being checked.
> Proposing a couple changes to the DecimalConversion:
>  * Check precision set on the decimal logical type. If value has greater 
> precision then error with more informative message
>  * Still check scale and error if value has a greater scale. However if the 
> scale in value is less, than it seems safe to update the scale and pad zero's 
> rather than error
>  * Do this for both Bytes and Fixed types
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Build failed in Jenkins: AvroJava #873

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #872

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #871

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #870

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #869

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #868

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #867

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #866

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #865

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

Build failed in Jenkins: AvroJava #864

[Apache Jenkins Server]

See 

Changes:


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on H38 (ubuntu) in workspace 

No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/avro # timeout=10
Fetching upstream changes from https://github.com/apache/avro
 > git --version # timeout=10
 > git fetch --tags --progress -- https://github.com/apache/avro 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/avro
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress -- https://github.com/apache/avro 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: unable to access 'https://github.com/apache/avro/': Could not 
resolve host: github.com

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H38
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor1196.invoke(Unknown 
Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy123.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at hudson.scm.SCM.checkout(SCM.java:504)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
 

[jira] [Commented] (AVRO-2668) Build failure without a C++ compiler

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108510#comment-17108510
 ] 

ASF subversion and git services commented on AVRO-2668:
---

Commit 414a51fdc1856083bb16851f09a4c61a48796132 in avro's branch 
refs/heads/master from Fabrice Fontaine
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=414a51f ]

AVRO-2668: Build failure without a C++ compiler

Specify that AvroC is a C project and remove tests_cpp.cpp to avoid the
following build failure if a C++ compiler is not found:

CMake Error at CMakeLists.txt:20 (project):
  The CMAKE_CXX_COMPILER:


/home/naourr/work/instance-2/output-1/host/bin/microblazeel-buildroot-linux-uclibc-g++

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.

Fixes:
 - 
http://autobuild.buildroot.org/results/135e246aa70f28c6b9aea5fd6b0eb9c7b45ebfe7

Signed-off-by: Fabrice Fontaine 


> Build failure without a C++ compiler
> 
>
> Key: AVRO-2668
> URL: https://issues.apache.org/jira/browse/AVRO-2668
> Project: Apache Avro
>  Issue Type: Bug
>  Components: c
>Reporter: Fabrice Fontaine
>Priority: Minor
>
> Build of AvroC fails without a C++ compiler:
> CMake Error at CMakeLists.txt:20 (project):
>  The CMAKE_CXX_COMPILER:
> /home/naourr/work/instance-2/output-1/host/bin/microblazeel-buildroot-linux-uclibc-g++
> is not a full path to an existing compiler tool.
> Tell CMake where to find the compiler by setting either the environment
>  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
>  to the compiler, or to the compiler name if it is in the PATH.
> More information on build failure can be found here:
>  - 
> http://autobuild.buildroot.org/results/135e246aa70f28c6b9aea5fd6b0eb9c7b45ebfe7



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [avro] dkulp merged pull request #754: AVRO-2668: Build failure without a C++ compiler

[GitBox]

dkulp merged pull request #754:
URL: https://github.com/apache/avro/pull/754


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [avro] dkulp merged pull request #837: AVRO-2766: Fix compilation error: 'size_t' does not name a type

[GitBox]

dkulp merged pull request #837:
URL: https://github.com/apache/avro/pull/837


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (AVRO-2766) [C++] Compilation failure size_t

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108507#comment-17108507
 ] 

ASF subversion and git services commented on AVRO-2766:
---

Commit 2b398cf179330ef545f2cae0daecd86a4aa3ac89 in avro's branch 
refs/heads/master from Laurent Stacul
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=2b398cf ]

AVRO-2766: Fix compilation error: 'size_t' does not name a type


> [C++] Compilation failure size_t
> 
>
> Key: AVRO-2766
> URL: https://issues.apache.org/jira/browse/AVRO-2766
> Project: Apache Avro
>  Issue Type: Bug
>  Components: build, c++
>Affects Versions: 1.9.2
>Reporter: Laurent Stacul
>Priority: Major
>
> With the following system:
> {code:java}
> $ uname -a
> Linux edf2927682ca 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 10.0.1 20200220 (experimental){code}
>  
> I received the compilation error:
> {code:java}
> g++  -DAVRO_SOURCE 
> -I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api
>  
> -I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/build
>  
> -I/home/docker/development/opensource-pack-builder/components/avro/DEPS/osp/Boost/latest/osp/include
>   -DNDEBUG -O3 -std=gnu++2a -fno-working-directory -ggdb3 -flto 
> -ffat-lto-objects -fuse-linker-plugin -Wall -O3 -DNDEBUG   -std=c++11 -fPIC 
> -o CMakeFiles/avrocpp_s.dir/impl/Zigzag.cc.o -c 
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc
> In file included from 
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc:20:
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:37:11:
>  error: 'size_t' does not name a type
>  37 | AVRO_DECL size_t encodeInt32(int32_t input, std::array 
> &output);
>  | ^~
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:26:1:
>  note: 'size_t' is defined in header ''; did you forget to '#include 
> '?
>  25 | #include "Config.hh"
>  +++ |+#include 
>  26 | /// \file
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
>  error: 'size_t' does not name a type
>  38 | AVRO_DECL size_t encodeInt64(int64_t input, std::array 
> &output);
>  | ^~
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
>  note: 'size_t' is defined in header ''; did you forget to '#include 
> '?{code}
> Regards,
> Laurent
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [avro] dkulp merged pull request #868: Use std::move when decoding maps and vectors

[GitBox]

dkulp merged pull request #868:
URL: https://github.com/apache/avro/pull/868


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (AVRO-2838) Schema in generated Java class is different than the original one

[Lukas Krecan (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Krecan updated AVRO-2838:
---
Description: 
If you generate Java classes from schema, {{SCHEMA$}} variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concerns. 

If it is not acceptable, would it be at least possible to add the 
{{originalSchema}} context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convey the idea.



  was:
If you generate Java classes from schema, `SCHEMA$` variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concerns. 

If it is not acceptable, would it be at least possible to add the 
`originalSchema` context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convey the idea.




> Schema in generated Java class is different than the original one
> -
>
> Key: AVRO-2838
> URL: https://issues.apache.org/jira/browse/AVRO-2838
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Lukas Krecan
>Priority: Major
> Attachments: AVRO.patch
>
>
> If you generate Java classes from schema, {{SCHEMA$}} variable differs from 
> the original schema. It causes issues like 
> [this|https://github.com/confluentinc/schema-registry/issues/868] and 
> [this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
> Schema registry.
> The issue happens when the schema in the registry is configured externally 
> and then you try to use generated Java class. The schema in the registry does 
> not match the schema in the class and thus the write is refused.
> Technically it's easy to fix (see the attached patch) but I guess there will 
> be some backward compatibility concerns. 
> If it is not acceptable, would it be at least possible to add the 
> {{originalSchema}} context variable so we could solve it using custom 
> template.
> The patch is not final, its purpose is just to convey the idea.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2838) Schema in generated Java class is different than the original one

[Lukas Krecan (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Krecan updated AVRO-2838:
---
Summary: Schema in generated Java class is different than the original one  
(was: Schema in generated Java class id different than the original one)

> Schema in generated Java class is different than the original one
> -
>
> Key: AVRO-2838
> URL: https://issues.apache.org/jira/browse/AVRO-2838
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Lukas Krecan
>Priority: Major
> Attachments: AVRO.patch
>
>
> If you generate Java classes from schema, `SCHEMA$` variable differs from the 
> original schema. It causes issues like 
> [this|https://github.com/confluentinc/schema-registry/issues/868] and 
> [this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
> Schema registry.
> The issue happens when the schema in the registry is configured externally 
> and then you try to use generated Java class. The schema in the registry does 
> not match the schema in the class and thus the write is refused.
> Technically it's easy to fix (see the attached patch) but I guess there will 
> be some backward compatibility concerns. 
> If it is not acceptable, would it be at least possible to add the 
> `originalSchema` context variable so we could solve it using custom template.
> The patch is not final, its purpose is just to convey the idea.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2838) Schema in generated Java class id different than the original one

[Lukas Krecan (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Krecan updated AVRO-2838:
---
Description: 
If you generate Java classes from schema, `SCHEMA$` variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concerns. 

If it is not acceptable, would it be at least possible to add the 
`originalSchema` context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convey the idea.



  was:
If you generate Java classes from schema, `SCHEMA$` variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concerns. 

If it is not acceptable, would it be at least possible to add the 
`originalSchema` context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convay the idea.




> Schema in generated Java class id different than the original one
> -
>
> Key: AVRO-2838
> URL: https://issues.apache.org/jira/browse/AVRO-2838
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Lukas Krecan
>Priority: Major
> Attachments: AVRO.patch
>
>
> If you generate Java classes from schema, `SCHEMA$` variable differs from the 
> original schema. It causes issues like 
> [this|https://github.com/confluentinc/schema-registry/issues/868] and 
> [this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
> Schema registry.
> The issue happens when the schema in the registry is configured externally 
> and then you try to use generated Java class. The schema in the registry does 
> not match the schema in the class and thus the write is refused.
> Technically it's easy to fix (see the attached patch) but I guess there will 
> be some backward compatibility concerns. 
> If it is not acceptable, would it be at least possible to add the 
> `originalSchema` context variable so we could solve it using custom template.
> The patch is not final, its purpose is just to convey the idea.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2838) Schema in generated Java class id different than the original one

[Lukas Krecan (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Krecan updated AVRO-2838:
---
Description: 
If you generate Java classes from schema, `SCHEMA$` variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concerns. 

If it is not acceptable, would it be at least possible to add the 
`originalSchema` context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convay the idea.



  was:
If you generate Java classes from schema, `SCHEMA$` variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concern. 

If it is not acceptable, would it be at least possible to add the 
`originalSchema` context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convay the idea.




> Schema in generated Java class id different than the original one
> -
>
> Key: AVRO-2838
> URL: https://issues.apache.org/jira/browse/AVRO-2838
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Reporter: Lukas Krecan
>Priority: Major
> Attachments: AVRO.patch
>
>
> If you generate Java classes from schema, `SCHEMA$` variable differs from the 
> original schema. It causes issues like 
> [this|https://github.com/confluentinc/schema-registry/issues/868] and 
> [this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
> Schema registry.
> The issue happens when the schema in the registry is configured externally 
> and then you try to use generated Java class. The schema in the registry does 
> not match the schema in the class and thus the write is refused.
> Technically it's easy to fix (see the attached patch) but I guess there will 
> be some backward compatibility concerns. 
> If it is not acceptable, would it be at least possible to add the 
> `originalSchema` context variable so we could solve it using custom template.
> The patch is not final, its purpose is just to convay the idea.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (AVRO-2838) Schema in generated Java class id different than the original one

[Lukas Krecan (Jira)]

Lukas Krecan created AVRO-2838:
--

 Summary: Schema in generated Java class id different than the 
original one
 Key: AVRO-2838
 URL: https://issues.apache.org/jira/browse/AVRO-2838
 Project: Apache Avro
  Issue Type: Bug
  Components: java
Reporter: Lukas Krecan
 Attachments: AVRO.patch

If you generate Java classes from schema, `SCHEMA$` variable differs from the 
original schema. It causes issues like 
[this|https://github.com/confluentinc/schema-registry/issues/868] and 
[this|https://github.com/confluentinc/schema-registry/issues/1352] when using 
Schema registry.

The issue happens when the schema in the registry is configured externally and 
then you try to use generated Java class. The schema in the registry does not 
match the schema in the class and thus the write is refused.

Technically it's easy to fix (see the attached patch) but I guess there will be 
some backward compatibility concern. 

If it is not acceptable, would it be at least possible to add the 
`originalSchema` context variable so we could solve it using custom template.

The patch is not final, its purpose is just to convay the idea.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2837) Java DecimalConversion handling of scale and precision

[Matthew McMahon (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108250#comment-17108250
 ] 

Matthew McMahon commented on AVRO-2837:
---

[^AVRO-2837.patch]

Created a pull request at [https://github.com/apache/avro/pull/884]

> Java DecimalConversion handling of scale and precision
> --
>
> Key: AVRO-2837
> URL: https://issues.apache.org/jira/browse/AVRO-2837
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java, logical types
>Affects Versions: 1.8.2, 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2837.patch
>
>
> Came across an interesting issue in Avro 1.8.2
> Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
> precision of 28).
> Due to an upstream bug, a value of 1070464558597365250.000 
> (1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
> DecimalConversion attempts to turn it into a Fixed type.
> This should have failed, as it has a precision of 34 and won't fit into the 
> 12 bytes (needs 14). However in 1.8.2 this still writes a value that 
> downstream processing then works out is invalid and errors.
> Basically the top 2 bytes are thrown away.
> This problem is fixed in 1.9.2 due to the change in 
> https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue 
> fails when it attempts to pass an offset of -2 to the System.arraycopy method.
> That seems ok, but is a bit of a red herring to the actual issue.
> Proposing a couple changes to the DecimalConversion:
>  * Check precision set on the decimal logical type. If value has greater 
> precision then error with more informative message
>  * Still check scale and error if value has a greater scale. However if the 
> scale in value is less, than it seems safe to update the scale and pad zero's 
> rather than error
>  * Do this for both Bytes and Fixed types
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2837) Java DecimalConversion handling of scale and precision

[Matthew McMahon (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew McMahon updated AVRO-2837:
--
Description: 
Came across an interesting issue in Avro 1.8.2

Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
precision of 28).

Due to an upstream bug, a value of 1070464558597365250.000 
(1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
DecimalConversion attempts to turn it into a Fixed type.

This should have failed, as it has a precision of 34 and won't fit into the 12 
bytes (needs 14). However in 1.8.2 this still writes a value that downstream 
processing then works out is invalid and errors.

Basically the top 2 bytes are thrown away.

This problem is fixed in 1.9.2 due to the change in 
https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue fails 
when it attempts to pass an offset of -2 to the System.arraycopy method.

That seems ok, but is a bit of a red herring to the actual issue, and precision 
is still not actually being checked.

Proposing a couple changes to the DecimalConversion:
 * Check precision set on the decimal logical type. If value has greater 
precision then error with more informative message
 * Still check scale and error if value has a greater scale. However if the 
scale in value is less, than it seems safe to update the scale and pad zero's 
rather than error
 * Do this for both Bytes and Fixed types

 

  was:
Came across an interesting issue in Avro 1.8.2

Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
precision of 28).

Due to an upstream bug, a value of 1070464558597365250.000 
(1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
DecimalConversion attempts to turn it into a Fixed type.

This should have failed, as it has a precision of 34 and won't fit into the 12 
bytes (needs 14). However in 1.8.2 this still writes a value that downstream 
processing then works out is invalid and errors.

Basically the top 2 bytes are thrown away.

This problem is fixed in 1.9.2 due to the change in 
https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue fails 
when it attempts to pass an offset of -2 to the System.arraycopy method.

That seems ok, but is a bit of a red herring to the actual issue.

Proposing a couple changes to the DecimalConversion:
 * Check precision set on the decimal logical type. If value has greater 
precision then error with more informative message
 * Still check scale and error if value has a greater scale. However if the 
scale in value is less, than it seems safe to update the scale and pad zero's 
rather than error
 * Do this for both Bytes and Fixed types

 


> Java DecimalConversion handling of scale and precision
> --
>
> Key: AVRO-2837
> URL: https://issues.apache.org/jira/browse/AVRO-2837
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java, logical types
>Affects Versions: 1.8.2, 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2837.patch
>
>
> Came across an interesting issue in Avro 1.8.2
> Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
> precision of 28).
> Due to an upstream bug, a value of 1070464558597365250.000 
> (1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
> DecimalConversion attempts to turn it into a Fixed type.
> This should have failed, as it has a precision of 34 and won't fit into the 
> 12 bytes (needs 14). However in 1.8.2 this still writes a value that 
> downstream processing then works out is invalid and errors.
> Basically the top 2 bytes are thrown away.
> This problem is fixed in 1.9.2 due to the change in 
> https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue 
> fails when it attempts to pass an offset of -2 to the System.arraycopy method.
> That seems ok, but is a bit of a red herring to the actual issue, and 
> precision is still not actually being checked.
> Proposing a couple changes to the DecimalConversion:
>  * Check precision set on the decimal logical type. If value has greater 
> precision then error with more informative message
>  * Still check scale and error if value has a greater scale. However if the 
> scale in value is less, than it seems safe to update the scale and pad zero's 
> rather than error
>  * Do this for both Bytes and Fixed types
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2837) Java DecimalConversion handling of scale and precision

[Matthew McMahon (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew McMahon updated AVRO-2837:
--
Attachment: AVRO-2837.patch

> Java DecimalConversion handling of scale and precision
> --
>
> Key: AVRO-2837
> URL: https://issues.apache.org/jira/browse/AVRO-2837
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java, logical types
>Affects Versions: 1.8.2, 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2837.patch
>
>
> Came across an interesting issue in Avro 1.8.2
> Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
> precision of 28).
> Due to an upstream bug, a value of 1070464558597365250.000 
> (1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
> DecimalConversion attempts to turn it into a Fixed type.
> This should have failed, as it has a precision of 34 and won't fit into the 
> 12 bytes (needs 14). However in 1.8.2 this still writes a value that 
> downstream processing then works out is invalid and errors.
> Basically the top 2 bytes are thrown away.
> This problem is fixed in 1.9.2 due to the change in 
> https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue 
> fails when it attempts to pass an offset of -2 to the System.arraycopy method.
> That seems ok, but is a bit of a red herring to the actual issue.
> Proposing a couple changes to the DecimalConversion:
>  * Check precision set on the decimal logical type. If value has greater 
> precision then error with more informative message
>  * Still check scale and error if value has a greater scale. However if the 
> scale in value is less, than it seems safe to update the scale and pad zero's 
> rather than error
>  * Do this for both Bytes and Fixed types
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [avro] maccamlc opened a new pull request #884: AVRO-2837: DecimalConversion handling of scale and precision

[GitBox]

maccamlc opened a new pull request #884:
URL: https://github.com/apache/avro/pull/884


   Improve the handling to check precision and not error if scale
   of value is less
   
   Make sure you have checked _all_ steps below.
   
   ### Jira
   
   - [x] My PR addresses the following [Avro 
Jira](https://issues.apache.org/jira/browse/AVRO-2837) issues and references 
them in the PR title.
   
   ### Tests
   
   - [x] My PR adds the following unit tests __OR__ does not need testing for 
this extremely good reason:
   
   TestDecimalConversion file added with tests of the success and expected 
error states
   
   ### Commits
   
   - [x] My commits all reference Jira issues in their subject lines. In 
addition, my commits follow the guidelines from "[How to write a good git 
commit message](https://chris.beams.io/posts/git-commit/)":
   
   ### Documentation
   
   - [x] In case of new functionality, my PR adds documentation that describes 
how to use it.
 - All the public functions and the classes in the PR contain Javadoc that 
explain what it does
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (AVRO-2837) Java DecimalConversion handling of scale and precision

[Matthew McMahon (Jira)]

Matthew McMahon created AVRO-2837:
-

 Summary: Java DecimalConversion handling of scale and precision
 Key: AVRO-2837
 URL: https://issues.apache.org/jira/browse/AVRO-2837
 Project: Apache Avro
  Issue Type: Improvement
  Components: java, logical types
Affects Versions: 1.9.2, 1.8.2
Reporter: Matthew McMahon


Came across an interesting issue in Avro 1.8.2

Configured a decimal logical type (Fixed type of size 12 with scale of 15 and 
precision of 28).

Due to an upstream bug, a value of 1070464558597365250.000 
(1.07046455859736525E+18 that is then rescaled to 15) appears, and the 
DecimalConversion attempts to turn it into a Fixed type.

This should have failed, as it has a precision of 34 and won't fit into the 12 
bytes (needs 14). However in 1.8.2 this still writes a value that downstream 
processing then works out is invalid and errors.

Basically the top 2 bytes are thrown away.

This problem is fixed in 1.9.2 due to the change in 
https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue fails 
when it attempts to pass an offset of -2 to the System.arraycopy method.

That seems ok, but is a bit of a red herring to the actual issue.

Proposing a couple changes to the DecimalConversion:
 * Check precision set on the decimal logical type. If value has greater 
precision then error with more informative message
 * Still check scale and error if value has a greater scale. However if the 
scale in value is less, than it seems safe to update the scale and pad zero's 
rather than error
 * Do this for both Bytes and Fixed types

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2836) SpecificCompiler does not add DecimalConversion when logical type is a Fixed type

[Matthew McMahon (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108231#comment-17108231
 ] 

Matthew McMahon commented on AVRO-2836:
---

[^AVRO-2836.patch]

Also created PR in Gitlab at [https://github.com/apache/avro/pull/883]

Appreciate any feedback

> SpecificCompiler does not add DecimalConversion when logical type is a Fixed 
> type
> -
>
> Key: AVRO-2836
> URL: https://issues.apache.org/jira/browse/AVRO-2836
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java, logical types
>Affects Versions: 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2836.patch
>
>
> I have updated to Avro 1.9.2 using the avro-maven-plugin to generate the 
> specific types.
> This is working nicely, except noticed the case of:
> {code:java}
> "fields": [
> {
>   "name": "unionOfFixedDecimal",
>   "type": ["null", {
> "namespace": "org.apache.avro.codegentest.testdata",
> "name": "FixedInUnion",
> "type": "fixed",
> "size": 12,
> "logicalType": "decimal",
> "precision": 28,
> "scale": 15
>   }]
> }] {code}
> This is a fixed type that has a logical type of decimal.
> When the source is generated, the type is BigDecimal. However the 
> DecimalConversion is missing and then it breaks when used.
> It seems easy to workaround by manually adding the logical conversion before 
> using.
> However the fix seems to be in 
> SpecificCompiler#getClassNamesOfPrimitiveFields which is used by 
> #getUsedConversionClasses



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2836) SpecificCompiler does not add DecimalConversion when logical type is a Fixed type

[Matthew McMahon (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthew McMahon updated AVRO-2836:
--
Attachment: AVRO-2836.patch

> SpecificCompiler does not add DecimalConversion when logical type is a Fixed 
> type
> -
>
> Key: AVRO-2836
> URL: https://issues.apache.org/jira/browse/AVRO-2836
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java, logical types
>Affects Versions: 1.9.2
>Reporter: Matthew McMahon
>Priority: Major
> Attachments: AVRO-2836.patch
>
>
> I have updated to Avro 1.9.2 using the avro-maven-plugin to generate the 
> specific types.
> This is working nicely, except noticed the case of:
> {code:java}
> "fields": [
> {
>   "name": "unionOfFixedDecimal",
>   "type": ["null", {
> "namespace": "org.apache.avro.codegentest.testdata",
> "name": "FixedInUnion",
> "type": "fixed",
> "size": 12,
> "logicalType": "decimal",
> "precision": 28,
> "scale": 15
>   }]
> }] {code}
> This is a fixed type that has a logical type of decimal.
> When the source is generated, the type is BigDecimal. However the 
> DecimalConversion is missing and then it breaks when used.
> It seems easy to workaround by manually adding the logical conversion before 
> using.
> However the fix seems to be in 
> SpecificCompiler#getClassNamesOfPrimitiveFields which is used by 
> #getUsedConversionClasses



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [avro] maccamlc opened a new pull request #883: AVRO-2836 Generated java includes logical type conversions

[GitBox]

maccamlc opened a new pull request #883:
URL: https://github.com/apache/avro/pull/883


   If the logical type is used for a Fixed type (potentially also Enum)
   then it should check if there are any conversions used, and
   include in the generated java source
   
   Make sure you have checked _all_ steps below.
   
   ### Jira
   
   - [ /] My PR addresses the following [Avro 
Jira](https://issues.apache.org/jira/browse/AVRO/AVRO-2836) issues and 
references them in the PR title.
   
   ### Tests
   
   - [ /] My PR adds the following unit tests __OR__ does not need testing for 
this extremely good reason:
   
   Added new test in TestNestedLogicalTypes that fails before this change, but 
succeeds with it
   
   ### Commits
   
   - [ /] My commits all reference Jira issues in their subject lines. In 
addition, my commits follow the guidelines from "[How to write a good git 
commit message](https://chris.beams.io/posts/git-commit/)":
   
   ### Documentation
   
   - [ /] In case of new functionality, my PR adds documentation that describes 
how to use it.
 - All the public functions and the classes in the PR contain Javadoc that 
explain what it does
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (AVRO-2836) SpecificCompiler does not add DecimalConversion when logical type is a Fixed type

[Matthew McMahon (Jira)]

Matthew McMahon created AVRO-2836:
-

 Summary: SpecificCompiler does not add DecimalConversion when 
logical type is a Fixed type
 Key: AVRO-2836
 URL: https://issues.apache.org/jira/browse/AVRO-2836
 Project: Apache Avro
  Issue Type: Bug
  Components: java, logical types
Affects Versions: 1.9.2
Reporter: Matthew McMahon


I have updated to Avro 1.9.2 using the avro-maven-plugin to generate the 
specific types.

This is working nicely, except noticed the case of:
{code:java}
"fields": [
{
  "name": "unionOfFixedDecimal",
  "type": ["null", {
"namespace": "org.apache.avro.codegentest.testdata",
"name": "FixedInUnion",
"type": "fixed",
"size": 12,
"logicalType": "decimal",
"precision": 28,
"scale": 15
  }]
}] {code}
This is a fixed type that has a logical type of decimal.

When the source is generated, the type is BigDecimal. However the 
DecimalConversion is missing and then it breaks when used.

It seems easy to workaround by manually adding the logical conversion before 
using.

However the fix seems to be in SpecificCompiler#getClassNamesOfPrimitiveFields 
which is used by #getUsedConversionClasses



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (AVRO-1567) Avro java tools tests fail with IBM JVM

[Ryan Skraba (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Skraba resolved AVRO-1567.
---
Resolution: Fixed

> Avro java tools tests fail with IBM JVM
> ---
>
> Key: AVRO-1567
> URL: https://issues.apache.org/jira/browse/AVRO-1567
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.7.4, 1.7.7
> Environment: RHEL 6.5 on x86_64
> IBM JVM 7.1.1.1
> HADOOP 2.4.1
>Reporter: Tony Reix
>Priority: Minor
> Fix For: 1.8.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> When using IBM JVM, compared to Oracle JVM, 25 of the Avro Tools tests fail.
> This is due to Avro using Hadoop which uses class:
>org/apache/hadoop/security/UserGroupInformation.java
> which makes use of:
>com.sun.security.auth.module.UnixLoginModule
> which does not exist in IBM JVM.
> Instead there is the class:
>com.ibm.security.auth.module.LinuxLoginModule
> that can be used in UserGroupInformation.java if the JVM is IBM.
> With a IBM-JVM patched version of Hadoop that takes care of the kind of JVM, 
> these 25 Avro Java Tools tests still fail because the pom.xml file of:
> lang/java/tools/
> says unconditionnaly (starting line 146 in Avro 1.7.7) :
>   
>   org.apache.hadoop
>   hadoop-core
> Using:
>   mvn -Phadoop2 -Dhadoop.version=2 test
> is of no help.
> In fact, hadoop-core exists only for old Hadoop versions (here version 
> 0.20.205.0 is used by Avro), and not for Hadoop 2.4.1 .
> Replacing hadoop-core by hadoop-client in lang/java/tools/pom.xml file does 
> fix the issue, as a work-around.
> However, a more rigorous solution is required, like it is done in 
> lang/java/mapred/pom.xm , where hadoop-core is associated with hadoop1 and 
> hadoop-client is associated with hadoop2 .
> I'm not an expert of Maven/pom.xml, and the pom.xml file of tools contains 
>  tags I have no idea. So, I'm not sure I can provide a correct 
> patch.
> I guess that a Maven/pom.xml expert should be able to fix this in some 
> minutes, plus testing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (AVRO-2227) CLONE - Python snappy error: "integer out of range for 'I' format code"

[Ryan Skraba (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Skraba resolved AVRO-2227.
---
Resolution: Duplicate

> CLONE - Python snappy error: "integer out of range for 'I' format code"
> ---
>
> Key: AVRO-2227
> URL: https://issues.apache.org/jira/browse/AVRO-2227
> Project: Apache Avro
>  Issue Type: Bug
>  Components: python
>Affects Versions: 1.5.4
> Environment: Linux michaelc 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 
> 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
> Ubuntu 11.04
> Python 2.7.1+ (ubuntu stock version)
> avro-1.5.4-py2.7.egg
> snappy-1.0.4 (c library)
> python-snappy-0.3.2
>Reporter: Jennifer b
>Assignee: Michael Cooper
>Priority: Major
> Fix For: 1.6.0
>
>
> The Python library for avro fails to write some blocks when used with snappy 
> compression.
> The error is:
> {code}
> Traceback (most recent call last):
>   File "tools/json_to_avro.py", line 74, in 
> writer.append(line)
>   File "/home/michaelc/.python/2.7/avro-1.5.4-py2.7.egg/avro/datafile.py", 
> line 185, in append
> self._write_block()
>   File "/home/michaelc/.python/2.7/avro-1.5.4-py2.7.egg/avro/datafile.py", 
> line 169, in _write_block
> self.encoder.write_crc32(uncompressed_data)
>   File "/home/michaelc/.python/2.7/avro-1.5.4-py2.7.egg/avro/io.py", line 
> 364, in write_crc32
> self.write(STRUCT_CRC32.pack(crc32(bytes)));
> struct.error: integer out of range for 'I' format code
> {code}
> From my investigation, str(crc32(bytes)) is showing negative integers, so the 
> issue seems to be fixed by masking the output.
> This fix appears to work from my limited testing:
> {code}
> --- io.old.py 2011-09-21 14:32:38.992544680 +1000
> +++ io.py 2011-09-21 14:33:11.492544686 +1000
> @@ -360,7 +360,7 @@
>  """
>  A 4-byte, big-endian CRC32 checksum
>  """
> -self.write(STRUCT_CRC32.pack(crc32(bytes)));
> +self.write(STRUCT_CRC32.pack(crc32(bytes) & 0x));
>  
>  #
>  # DatumReader/Writer
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (AVRO-1805) Maven dependecy of avro-tools without slf4j implementation

[Ryan Skraba (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Skraba resolved AVRO-1805.
---
Resolution: Fixed

> Maven dependecy of avro-tools without slf4j implementation
> --
>
> Key: AVRO-1805
> URL: https://issues.apache.org/jira/browse/AVRO-1805
> Project: Apache Avro
>  Issue Type: Sub-task
>  Components: java
>Reporter: Mohammad Salman
>Priority: Major
> Fix For: 1.5.1
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-1805) Maven dependecy of avro-tools without slf4j implementation

[Ryan Skraba (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108119#comment-17108119
 ] 

Ryan Skraba commented on AVRO-1805:
---

Hello!  There is a maven dependency for avro-tools without any dependencies, at 
least back to 1.5.1 as part of the parent task:

{code}

  org.apache.avro
  avro-tools
  1.9.2
  nodeps

{code}

> Maven dependecy of avro-tools without slf4j implementation
> --
>
> Key: AVRO-1805
> URL: https://issues.apache.org/jira/browse/AVRO-1805
> Project: Apache Avro
>  Issue Type: Sub-task
>  Components: java
>Reporter: Mohammad Salman
>Priority: Major
> Fix For: 1.5.1
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (AVRO-2490) Unable to add field to existing avro schema

[Ryan Skraba (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Skraba resolved AVRO-2490.
---
Fix Version/s: (was: 1.8.2)
   (was: 1.9.0)
   Resolution: Not A Bug

> Unable to add field to existing avro schema
> ---
>
> Key: AVRO-2490
> URL: https://issues.apache.org/jira/browse/AVRO-2490
> Project: Apache Avro
>  Issue Type: Bug
>Reporter: Martin Mucha
>Priority: Major
>
> As described in 
> [https://docs.oracle.com/database/nosql-12.1.3.4/GettingStartedGuide/schemaevolution.html#changeschema-rules]
>  
> I should be able to extend AVRO schema by adding optional and(or?) 
> default-having field. If I do that though, deserialization fails for me. It 
> happens for version 1.8.2 and 1.9.0 as well.
>  
> Some cases:
> A) If I add new field defined as:
> {code:java}
> { "name": "newColumn", "type": ["null","string"], "default": null}{code}
> deserialization will fail with:
>  
> {code:java}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5 at 
> org.apache.avro.io.parsing.Symbol$Alternative.getSymbol(Symbol.java:424) at 
> org.apache.avro.io.ResolvingDecoder.doAction(ResolvingDecoder.java:290) at 
> org.apache.avro.io.parsing.Parser.advance(Parser.java:88) at 
> org.apache.avro.io.ResolvingDecoder.readIndex(ResolvingDecoder.java:267) at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:179)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:232)
>  at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:222)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:175)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:179)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:232)
>  at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:222)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:175)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:145) 
> at 
> tech.allegro.schema.json2avro.converter.JsonAvroConverter.convertToJson(JsonAvroConverter.java:83){code}
>  
> if I add new field defined as:
> {code:java}
> { "name": "newColumn", "type": "string", "default": ""}{code}
> {{or}}
> {code:java}
> { "name": "newColumn", "type": "string", "default": "incorrect"}{code}
> (assuming I will fix it later in app)
> deserialization will fail with:
>  
> {code:java}
> Caused by: org.apache.avro.AvroRuntimeException: Malformed data. Length is 
> negative: -1 at 
> org.apache.avro.io.BinaryDecoder.doReadBytes(BinaryDecoder.java:336) at 
> org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:263) at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:422)
>  at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:414)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:181)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:232)
>  at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:222)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:175)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:179)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:232)
>  at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:222)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:175)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:145) 
> at 
> tech.allegro.schema.json2avro.converter.JsonAvroConverter.convertToJson(JsonAvroConverter.java:83){code}
>  
> {{what code does fail like that(that ± con

[jira] [Commented] (AVRO-2490) Unable to add field to existing avro schema

[Ryan Skraba (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108110#comment-17108110
 ] 

Ryan Skraba commented on AVRO-2490:
---

Hello!  This looks like a misunderstanding about what schema evolution means, 
and probably not a bug.

The linked Oracle NoSQL documentation says that you can change an Avro schema 
by adding a field with a default.  This **IS** always true, but when you are 
using the Java SDK by itself, you need to always provide the actual original 
schema (i.e. a.k.a the old "writer" schema that generated the serialized data) 
*_as well as_* the evolved schema (i.e. the new "reader" schema with your new 
field).

The binary data is read using the original schema and mapped into the evolved 
schema.  Your last line of code should use the two parameter constructor for 
[GenericDatumReader|https://avro.apache.org/docs/1.8.2/api/java/org/apache/avro/generic/GenericDatumReader.html#GenericDatumReader(org.apache.avro.Schema,%20org.apache.avro.Schema)].
  There's a test case [demonstrating 
this|https://github.com/apache/avro/blob/70260919426f89825ca148f5ee815f3b2cf4764d/lang/java/avro/src/test/java/org/apache/avro/TestSchemaBuilder.java#L779].

{code}
GenericRecord record = (GenericRecord)(new GenericDatumReader(originalSchema, 
evolvedSchema)).read((Object)null, binaryDecoder);
{code}

The Oracle NoSQL doc implies that it is keeping track of the schemas being 
used, and using the the "correct" writer and reader schemas automatically.  If 
you are writing your own code with the Java SDK, you need to keep track of your 
schemas yourself.



> Unable to add field to existing avro schema
> ---
>
> Key: AVRO-2490
> URL: https://issues.apache.org/jira/browse/AVRO-2490
> Project: Apache Avro
>  Issue Type: Bug
>Reporter: Martin Mucha
>Priority: Major
> Fix For: 1.9.0, 1.8.2
>
>
> As described in 
> [https://docs.oracle.com/database/nosql-12.1.3.4/GettingStartedGuide/schemaevolution.html#changeschema-rules]
>  
> I should be able to extend AVRO schema by adding optional and(or?) 
> default-having field. If I do that though, deserialization fails for me. It 
> happens for version 1.8.2 and 1.9.0 as well.
>  
> Some cases:
> A) If I add new field defined as:
> {code:java}
> { "name": "newColumn", "type": ["null","string"], "default": null}{code}
> deserialization will fail with:
>  
> {code:java}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5 at 
> org.apache.avro.io.parsing.Symbol$Alternative.getSymbol(Symbol.java:424) at 
> org.apache.avro.io.ResolvingDecoder.doAction(ResolvingDecoder.java:290) at 
> org.apache.avro.io.parsing.Parser.advance(Parser.java:88) at 
> org.apache.avro.io.ResolvingDecoder.readIndex(ResolvingDecoder.java:267) at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:179)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:232)
>  at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:222)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:175)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:179)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:232)
>  at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:222)
>  at 
> org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:175)
>  at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153) 
> at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:145) 
> at 
> tech.allegro.schema.json2avro.converter.JsonAvroConverter.convertToJson(JsonAvroConverter.java:83){code}
>  
> if I add new field defined as:
> {code:java}
> { "name": "newColumn", "type": "string", "default": ""}{code}
> {{or}}
> {code:java}
> { "name": "newColumn", "type": "string", "default": "incorrect"}{code}
> (assuming I will fix it later in app)
> deserialization will fail with:
>  
> {code:java}
> Caused by: org.apache.avro.AvroRuntimeException: Malformed data. Length is 
> negative: -1 at 
> org.apache.avro.io.BinaryDecoder.doReadBytes(BinaryDecoder.java:336) at 
> org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:263) at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:422)
>  at 
> org.apache.avro