I think I've found the source of the issue. We are using assert-core on
our fork of the repository, which is attempting to pull in junit-5.4.0.
junit-5.4.0 doesn't seem to be published on either of the https
repositories, so ant tries to hit the http as a backup and then fails with
the error
I agree that something feels wonky on the Circle container. I was able to
successfully build locally.
I SSHed into the container, cleared out .m2/repository and still can't get it
to build. Using ant 1.10.7 with environment:
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build
Hey Michael,
That’s basically what I did, but still getting the error unfortunately. The
first artifact does seem to recognize to use https, but the transitive
dependency does not.
Thanks
> On Jan 15, 2020, at 7:00 PM, Michael Shuler wrote:
>
> You could cherry-pick sha
I just did a quick `rm -r ~/.m2/repository/` so the build would download
everything, and with 2.2.14 tag + 63ff65a8dd, the build succeeded for me
fine, pulling everything from https. Not sure where to go, unless the
circleci container is somehow contaminated with http cached data.
Michael
On
Bleh, sorry, you updated those, right.
I don't see any other related commits to build.xml nor
build.properties.default.. Some elderly sub-dependent that has an http
URL in it, perhaps?
--
Michael
On 1/15/20 5:44 PM, Leon Zaruvinsky wrote:
Hey all,
I'm having trouble with the building
You could cherry-pick sha 63ff65a8dd3a31e500ae5ec6232f1f9eade6fa3d which
was committed after the 2.2.14 release tag.
https://github.com/apache/cassandra/commit/63ff65a8dd3a31e500ae5ec6232f1f9eade6fa3d
--
Kind regards,
Michael
On 1/15/20 5:44 PM, Leon Zaruvinsky wrote:
Hey all,
I'm having
Hey all,
I'm having trouble with the building Cassandra 2.2.14 on CircleCI since
Central Repo has stopped supporting http.*
*
https://central.sonatype.org/articles/2020/Jan/15/501-https-required-error/
I've updated the build.properties and build.xml files to use https.
However, it seems that
Thank you. I have an insight now.
Regards,
Osman
On Wed, 15 Jan 2020 at 19:18, Reid Pinchback wrote:
>
> Oh, duh. Revise that. I was forgetting that multi-dc writes are sent to a
> single node in the other dc and tagged to be forwarded to other nodes within
> the dc.
>
> So your
Oh, duh. Revise that. I was forgetting that multi-dc writes are sent to a
single node in the other dc and tagged to be forwarded to other nodes within
the dc.
So your quick-and-dirty estimate would be more like (write volume) x 2 to leave
headroom for random other mechanics.
R
On
I would think that it would be largely driven by the replication factor. It
isn't that the sstables are forklifted from one dc to another, it's just that
the writes being made to the memtables are also shipped around by the
coordinator nodes as the writes happen. Operations at the sstable
Hello,
Is there any way to calculate inter dc bandwidth requirements for
proper operation?
I can't find any info about this subject.
Can we say, how much sstable collected at one dc has to be transferred to other?
I can calculate bandwidth with generated sstable then.
I have twcs with one hour
11 matches
Mail list logo
