You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JRuby version (jruby -v) and command line (flags, JRUBY_OPTS, etc): 9.3.0.0
Operating system and platform (e.g. uname -a): Darwin Andys-MacBook-Pro.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64
Other relevant info you may wish to add:
gem --version returns 3.2.28
Expected Behavior
Running gem push path_to_gem.gem should result in releasing the gem to RubyGems.org successfully.
This works in jruby-9.2.19.0
Actual Behavior
In jruby-9.3.0.0, I get a broken pipe IOError when running gem push path_to_gem.gem:
% gem push pkg/glimmer-dsl-swt-4.21.0.1.gem
Pushing gem to https://rubygems.org...
ERROR: While executing gem ... (IOError)
Broken pipe
It works fine in ruby-3.0.2 and jruby-9.2.19.0. My Internet works well and the same in all cases.
Could you try to run this with more debugging output, via some combination of --verbose and --backtrace and --debug?
I'm trying to figure out if there's a dummy RG server somewhere I could use to test this. If you can get more debugging output we might have enough information to narrow the scope of this issue.
Oh and thank you for the extra logging output! Seems like this ties the issue back to jruby-openssl. However, I think we shipped the same jruby-openssl in 9.2.19.0 so there's more to the story.
I was able to push a gem with the 9.3.0.0 release (installed via rvm) so we need to dig deeper on why this is failing for you.
[] ~/projects/weakling $ jruby -v
jruby 9.3.0.0 (2.6.8) 2021-09-17 85c20e780f OpenJDK 64-Bit Server VM 25.222-b10 on 1.8.0_222-b10 +jit [darwin-x86_64]
[] ~/projects/weakling $ gem -v
3.2.14
Sorry, I forgot to provide the full version line, which indicates I am using JDK 16.
% jruby -v
jruby 9.3.0.0 (2.6.8) 2021-09-17 85c20e780f Java HotSpot(TM) 64-Bit Server VM 16.0.2+7-67 on 16.0.2+7-67 +jit [darwin-x86_64]
% gem -v
3.2.28
% rvm --version
rvm 1.29.12 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io]
% uname -a
Darwin Andys-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64
I am using MacOS Big Sur 11.6
Perhaps you would get different results with JDK 16?
I just tried with Fedora Core 34 using both Java 8 and Java 16 and this also works for me. Just thinking outloud perhaps some SSL settings is different for your env than ours and this is tripping over something?
Activity
headius commentedon Oct 6, 2021
Could you try to run this with more debugging output, via some combination of
--verboseand--backtraceand--debug?I'm trying to figure out if there's a dummy RG server somewhere I could use to test this. If you can get more debugging output we might have enough information to narrow the scope of this issue.
AndyObtiva commentedon Oct 6, 2021
OK, I just did and here is what I got:
I deleted my
~/.gemrc, which had the--no-documentoption and ran thegem pushcommand again, getting this output:headius commentedon Oct 7, 2021
On master, I was able to push a gem ok (Java 11, macOS 10.15). I will try with released 9.3 and see if I can repro.
headius commentedon Oct 7, 2021
Oh and thank you for the extra logging output! Seems like this ties the issue back to jruby-openssl. However, I think we shipped the same jruby-openssl in 9.2.19.0 so there's more to the story.
I was able to push a gem with the 9.3.0.0 release (installed via rvm) so we need to dig deeper on why this is failing for you.
@kares Any thoughts here?
AndyObtiva commentedon Oct 7, 2021
Thanks for giving it a try.
Sorry, I forgot to provide the full version line, which indicates I am using JDK 16.
I am using MacOS Big Sur 11.6
Perhaps you would get different results with JDK 16?
headius commentedon Oct 8, 2021
I will give that a shot. I also have a macOS 11 system here that I'll try to fire up tomorrow.
headius commentedon Oct 11, 2021
Pushing on Java 16 appears to work fine for me locally, on Catalina.
enebo commentedon Oct 12, 2021
I just tried with Fedora Core 34 using both Java 8 and Java 16 and this also works for me. Just thinking outloud perhaps some SSL settings is different for your env than ours and this is tripping over something?
AndyObtiva commentedon Oct 12, 2021
Thank you for testing with Java 16.
Please keep in mind that gem pushing works for me on the same machine setup with earlier versions of JRuby and with CRuby as well.
Also, did you notice the linkage from this issue by michaelklishin? ruby-amqp/march_hare#156
It seems he encountered the same issue. He also had to resort to CRuby to push his gem.
headius commentedon Oct 12, 2021
Right, I believe you, I'm just trying to find a way to reproduce it here so we can fix it. I will try a few more things.
headius commentedon Oct 12, 2021
This is an x86_64 MBP, yes?
headius commentedon Oct 12, 2021
I attempted to push with Java 16 (x86_64) on a macOS 11.5 M1 machine and it also pushed ok there.
Need to figure out how to get more information from your system. Have we tried all the relevant flags at this point?
headius commentedon Oct 12, 2021
@michaelklishin If you are able to reproduce we could use another data point. JDK version? OS version? Hardware?
AndyObtiva commentedon Oct 13, 2021
“This is an x86_64 MBP, yes?”
Yes, correct.
michaelklishin commentedon Oct 13, 2021
I ran into this with JDK 13.0.2 on MacOS 11.6 (Intel hardware).
39 remaining items
Convert IOException to Ruby exception correctly
[fix] convert IOException to Ruby exception correctly
[fix] SSL write data loss on non-blocking partial flush (#242)
[fix] SSL write data loss on non-blocking partial flush (#242)
[test] replace internal Ruby test with Java unit test
[fix] SSL write data loss on non-blocking partial flush (#242)
[test] replace internal Ruby test with Java unit test
[fix] SSL write loss on non-blocking partial flush (#242)
[test] introduce SSLSocketTest (unit test)
[fix] SSL write loss on non-blocking partial flush (#242)
[test] introduce SSLSocketTest (unit test)