We are using ClearCase 9.0.1.4 and version 1.6.3 of the plugin and run into
this issue. How do I get the endViewDelay fix?
*14:47:45* [Label Job] $ /usr/atria//bin/cleartool endview -server
Jenkins_view
*14:47:45*
*14:47:45* [Label Job] $ /usr/atria//bin/cleartool catcs -tag Jenkins_view
*1
Hi Vincent,
1.5.2 works fine. Thanks for the assistance and the fix.
Sascha
Am Montag, 7. Juli 2014 09:54:10 UTC+2 schrieb Vincent Latombe:
>
> I just released 1.5.2 with the form fix.
>
> Vincent
>
>
> 2014-07-07 9:07 GMT+02:00 Sascha Herrmann >:
>
>> Hi!
>>
>> Thanks. It seems to be just a th
I just released 1.5.2 with the form fix.
Vincent
2014-07-07 9:07 GMT+02:00 Sascha Herrmann :
> Hi!
>
> Thanks. It seems to be just a thing of saving the setting. When I put the
> "2" directly into the endViewDelay tag in the XML and then restart Jenkins,
> then the delay is applied fine and I s
Hi!
Thanks. It seems to be just a thing of saving the setting. When I put the
"2" directly into the endViewDelay tag in the XML and then restart Jenkins,
then the delay is applied fine and I see the "2" in the settings.
Sascha
--
You received this message because you are subscribed to the Goo
Eh, if it comes back to 0, there must be an issue, I will check that
back.
Vincent
2014-07-04 17:00 GMT+02:00 Sascha Herrmann :
> Hi!
>
> Version 1.5.1 doesn't work or I am doing it wrong.
>
> I set the delay to "2" in the settings, but when I come back to the
> settings after saving, it's
Hi!
Version 1.5.1 doesn't work or I am doing it wrong.
I set the delay to "2" in the settings, but when I come back to the
settings after saving, it's "0" again, and there is no delay applied in
endview according to the logs.
Sascha
--
You received this message because you are subscribed to
Hi Vincent,
sure that's okay. I was going for a simple system property since the error
(from your reaction) seemed a bit exotic and has only been reported by me
so far.
But configuration in the plugin settings is great, thanks. So I will not
create that pull request,
Sascha
Am Montag, 30. Jun
Hi,
I have implemented your suggestion. I have added a configurable delay after
any endview call (for n. It is set to 0 by default and you can configure it
through the global plugin settings.
Corresponding build is
https://jenkins.ci.cloudbees.com/job/plugins/job/clearcase-plugin/71/org.jenkins-c
That was quick. It doesn't work. Immediate timeouts after endview again.
Sascha
Am Montag, 30. Juni 2014 12:21:00 UTC+2 schrieb Sascha Herrmann:
>
> Hi Vincent,
>
> thanks. I will try. I doubt that it will bring an improvement, because
> we're already ending the view_server processes after the b
Hi Vincent,
thanks. I will try. I doubt that it will bring an improvement, because
we're already ending the view_server processes after the build using a
batch script as I mentioned previously.
I will update the post with my findings.
Thanks again.
Sascha
Am Montag, 30. Juni 2014 09:32:19 UT
Hi Sascha,
could you try the given build [1] and see whether you still encounter the
issue? I have added a call to endview after the checkout. I believe it may
also help with the delay you are observing when called initially (because
it may be dependant on the number of active views on the host).
Builds run fine now. Seems that endview takes some time to finish before
the next command can be called.
Would it be possible to get a delay like that into the official plugin?
Maybe configurable with a system property?
Sascha
Am Freitag, 27. Juni 2014 08:56:09 UTC+2 schrieb Sascha Herrmann:
Hi!
I have quickly added a "Thread.sleep( 5000 )" into
BaseSnapshotCheckoutAction#checkout() between endview and setcs on our
build machine and will monitor if that improves things.
Maybe ClearTool.endViewServer() would be the better place for that delay.
Not sure.
5000 millis is probably too m
Hi!
Thanks for your reply. IMHO CC isn't better than Subversion or Git.
We're using snapshot views because we were running on problems with dynamic
views with our particular CC version on our particular (old) Windows Server
version we're running.
So we had to convert all dynamic views (also the
Hmmm Google Groups ... couldn't edit the posting ... tried to delete
error on delete wrote a new reply now original reply gone
after all.
We're on Windows, so there is no limit command. But we can run as many
Perforce builds concurrently as we want. I doubt it's an OS limit.
Hi,
the reason the endview is issued is to end any ongoing update process on
that view (that may have been interrupted in a previous run, leaving
clearcase in an unclean state).
Maybe the reason setcs fails for you is because endview is still running
behind and takes too much time? I'm surprised
Am 23.06.2014 10:15, schrieb Sascha Herrmann:
> But there seems to be a (hardcoded?) limit of how many view_server
> processes the albd can spawn.
Not that I'm aware of.
BTW: Why snapshot views? If you don't use dynamic views, CC isn't any
better than Subversion or Git.
Bye...
Dirk
--
*D
Hi Jes!
Me again :o)
Totally forgot. You being an expert in the plugin, what is the reason for
the "endview" before the "setcs"? Our IT pinpoints this as the problem,
although I don't see why there should be an immediate timeout in the first
place. The commands issued earlier by the plugin sta
Many different jobs at the same time. The limit seems to exist. There are
not that many processes running on that machine since we solely use it for
Jenkins. Concurrent Perforce builds we can have as many as we want, no
problem there. But with Clearcase we noticed that we get errors from
cleart
Hey sascha,
with out vein an expert in this specific plugin, could you maybe tell if
you by, parallel builds mean that you have a lot of different jobs build at
the same time or you have a lot of concurrent executions of the same job?
If the later then look for view name, they might use the same n
20 matches
Mail list logo
