We have multiple perforce servers set up and our projects pull code from both servers when building. I'm using the Multiple SCMs plugin to handle clientspecs to both of these servers. Everything seems to work except for the polling. It appears that only one SCMRevisionState is attached to a build or that only one is being retrieved when polling for changes. Here's the polling log showing the issue:

Started on Aug 1, 2014 2:21:13 PM
Polling SCM changes on dwagner-dev-t36
Looking for changes...
Using node: dwagner-dev-t36
Using remote perforce client: <clientspec 1>
[jenkins] $ p4 workspace -o <clientspec 1>
[jenkins] $ p4 counter change
[jenkins] $ p4 -s changes -s submitted <view filter 1>...@3477236,@10592344
Latest submitted change selected by workspace is 10592053
[jenkins] $ p4 describe -s 10592053
[jenkins] $ p4 -G where //...
Looking for changes...
Using node: dwagner-dev-t36
Using remote perforce client: <clientspec 2>
[jenkins] $ p4 workspace -o <clientspec 2>
[jenkins] $ p4 counter change
[jenkins] $ p4 -s changes -s submitted <view filter 2>...@3477236,@3490195
No changes found.
Done. Took 0.56 sec
Changes found

The problem is visible on this line:

[jenkins] $ p4 -s changes -s submitted <view filter 1>...@3477236,@10592344

The starting changelist is the changelist from the second account. Digging through the code, it looks like the Multiple SCMs plugin uses scm.getKey() to differentiate SCMRevisionStates for each account. The Perforce plugin looks like it uses the parent hudson.scm.SCM.getKey(), which simply returns the class name.

I don't have the facility to debug, but my guess is that implementing PerforceSCM.getKey() such that each account returned a different key based on P4PORT and the base clientspec would fix the problem.