Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-35696] - Allow registering BC on the slave #10

Merged
merged 9 commits into from Jun 15, 2016

Conversation

alvarolobato
Copy link
Member

New method on the API to allow registering BC on the slave. The plugin is responsible for calling the method with a Channel to the slave.

Multiple calls to register BC on the same Channel will have no effect.

JENKINS-35696

@alvarolobato
Copy link
Member Author

@reviewbybees esp @amuniz @stephenc

@ghost
Copy link

ghost commented Jun 14, 2016

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

public static boolean registerBCOnSlave(@Nonnull Channel channel) throws Exception {
if (channel.getProperty(BOUNCYCASTLE_REGISTERED) == null) {
// pre-loading the bouncyclastle jar to make sure the JVM reconizes the signature
channel.preloadJar(PEMEncodable.class.getClassLoader(), BouncyCastleProvider.class);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never used preloadJar. Is the plugin classloader the right one to use here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, AFIK you need a class loader that know where the correct class is loaded from, in this case BouncyCastleProvider.class

@amuniz
Copy link
Member

amuniz commented Jun 14, 2016

🐝

@andresrc
Copy link

I'd include some synchronization on the channel (indirectly, like the guava cache using weak references in the keys) in case more than one plugin tries to register in parallel.

Apart from that, if the class loader used is the correct one 🐝

@alvarolobato
Copy link
Member Author

@andresrc yes it can be done, but the addProvider is an innocuous operation, the second time does nothing. And the preloadJar is just a preload... so maybe it's better to keep it simple. Thanks for the review

@stephenc
Copy link
Member

The local-side property value can be a Future for completion. That way if it is missing you have an almost idempotent write and worst case make two remoting calls before completing the future. All subsequent code that sees the future can just get the future ... and for the win we can rethrow the fiture's exception if we failed so that the failure reason is available to all, not burried in the logs that were rotated away because the system has been up too long

/**
* Callable to start the remote agent.
*/
public class BCRegisterer extends MasterToSlaveCallable<Boolean, Exception> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@restricted as you have a utility method to manage the call

@stephenc
Copy link
Member

🐛 the static utility method is not in an intuitive class

@stephenc
Copy link
Member

Also see my for the win comment wrt exceptions

@alvarolobato
Copy link
Member Author

@stephenc I've moved the method to the Callable and made the constructor private. I'm returning the Future from the remote call.

I'll have to leave the Exception re-throwing for a future improvement as I don't have time right now and we need to cut a version. I've created JENKINS-35914. I will involve creating the future (not returning the one from the asyncCall) and execute the preloadJar and the remote call all together.

@stephenc
Copy link
Member

@alvarolobato alvarolobato#1 is the improvements that should be made IMHO. I hope you can see that this is not as hard... basically you get the re-throw for free and using ChannelProperty means that we:

  1. Know it won't be serialized
  2. Know nobody else can peek into the property

@alvarolobato
Copy link
Member Author

Thanks @stephenc, looks great. I don't have that knowledge about the API (yet), commiting

@stephenc
Copy link
Member

🐝

2 similar comments
@andresrc
Copy link

🐝

@amuniz
Copy link
Member

amuniz commented Jun 15, 2016

🐝

@alvarolobato alvarolobato merged commit 588e57b into jenkinsci:master Jun 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants