THRIFT-3000 .NET implementation has trouble with mixed IP modes

[Jens-G]

Client: C#
Patch: sharpdevel icode666@github & Jens Geyer

TcpListener and TcpClient are created based on the capabilities of the used runtime framework. For windows the changes automatically handle IPv4 and IPv6 sockets. In mono it behaves as before.

When using TcpListener and TcpClient it depends on the network configuration if IPv4 or IPv6 is used. By upgrading the framework to .NET 4.5 the DualMode can be set on the sockets of the listener and the client. The sockets then try to establish IPv6 sockets before they fallback to IPv4

[jeking3]

Did this complete a CI build? Someone suggested in analysis of my pull request to THRIFT-2850 that this changeset is the root cause.

[Jens-G]

Sure it did: https://builds.apache.org/job/Thrift/

Travis is only an indicator with unfortunalety some limitations. That's not to say that Travis is not a good tool, but it is not the sacred last word either. Anyway, I'm going to revert that one. Seems we need some more work here.

[nsuke]

@Jens-G, can you take a look at #459 before reverting ?

As to the Travis-CI failure, I'm aware that "true" CI is the Jenkins but it would be nice if Travis failures get more attention, because it is easily accessible to all contributors, not only to maintainers.

To name a few key differences:

• I can run builds and tests on my own Travis-CI account and verify PRs before submitting, not for Jenkins
• I can suggest working Travis-CI test changes though PRs but don't know any way to do it for Apache Jenkins servers

IMO, @jeking3's way of being very serious about Travis failure is good way to reduce not only occasional regressions but also maintainers' work.

What is good about Jenkins setups ?

[Jens-G]

IMO, @jeking3's way of being very serious about Travis failure is good way to reduce not only occasional regressions but also maintainers' work.

Absolutely. I'm 100% behind Travis.

What is good about Jenkins setups ?

That's where the real stuff happens ;-)

[nsuke]

How about having unified base for testing ?
Can we have Jenkins build step scripts inside the repository and invoke them from both Jenkins and Travis/Appveyer ?

[Jens-G]

They both call the usual suspects: bootstrapsh && configure && make &&... or cmake. The environment makes the difference.

[nsuke]

No, Jenkins not calling cross tests made the difference.

In fact, the log shows that Jenkins doesn't even build following languages at all (Building : no):

• C (GLib)
• Ruby
• Haxe
• Haskell
• Erlang
• Go
• D
• NodeJS

I couldn't find any evidence of make check being run either.

I have to say it does not do the job well.

The real problem is that Jenkins on Apache servers cannot evolve as fast as the code base because of its closed nature.

[jfarrell]

we need to transition our jenkins build over to using the docker containers so we have more control over them and then can run whatever we like inside that. on my list for pre 1.0