Restart to update .jar...

[Fonceur]

So I had older version of GKusnick Studio Tools and SageTCPServer installed, I created a SagePluginsDev.xml to install a new version of SageTCPServer (and dependency) through the Plugin interface. After the download SageTV says it required a restart to install those new .jar, fair enough. But from the sagetv_0.txt file, it's obvious it is still using the older files. Looking at the SageTV\SageTV\JARs folder I see the new files with some .5 or such appended to them. Now if I restart SageTV again, they do get renamed and used properly, but what was the point of the "built-in restart" if it's not going to install the new files in the first place? Am I missing something, or is that a bug in the release candidate 2?

[joshuad156]

I have run into this issue myself, and mildly disappointed to see nobody here with any ideas as to why this may happen.

I'm developing my first SageTV plugin. I'm also kinda new to Java (done some Java Scripts in my past, but never full Java development). I'm rapidly exporting new versions during development and redeploying updated packages with updated version numbers in the SageTVPluginsDev.xml. SageTV client running locally on the server is detecting that I have an update available. I run the update, and it tells me I need to restart. The server clearly restarts, as I see the sage log file cycle. However, when my plugin launches, it's clearly launching the OLD version. After one more manual server restart and the new jar files becomes active.

I'll take any suggestions about what's happening as I'm clueless. Perhaps I'm doing something wrong, or I have the server configured wrong somehow. I see messages in the debug log after the update completes about staging the new jar file, but after the first restart, I don't see any log info about updating the jar file.

I'm not sure I've ever seen this behavior on my Production SageTV server before, but then again I'm not sure how thoroughly I've been checking!

[Fonceur]

The simplest solution I found is to just stop SageTV and its service, then drop the .jar in the folder. Of course if you actually need to test the deployment, then that wouldn't help you.

[GKusnick]

Originally Posted by Fonceur

The simplest solution I found is to just stop SageTV and its service, then drop the .jar in the folder.

This will likely just compound the problem. Manually overwriting JARs will break the consistency of revision dates and MD5 sums recorded by the plugin system and interfere with its ability to stage the installation of updated JARs.

For reliable plugin updates, always deploy your modified JARs through the plugin installer system and don't mess directly with the contents of the JARs folder.

[Fonceur]

Originally Posted by GKusnick

For reliable plugin updates, always deploy your modified JARs through the plugin installer system and don't mess directly with the contents of the JARs folder.

Except that the whole point is that it is not reliable and might require and extra restart to really take hold...

[joshuad156]

Originally Posted by GKusnick

For reliable plugin updates, always deploy your modified JARs through the plugin installer system and don't mess directly with the contents of the JARs folder.

I'd like to continue deploying this way, but still nobody seems to address the issue raised above. Does anyone else observe this same issue? Does everyone just "work around it" by restarting twice?

Is it standard convention to name the .jar file with a static name, or would it be better to include a version number in the .jar file name? I guess I could just try it but I'm at work now and can't test this from here.

[Fonceur]

It's the .zip that contains the version number, the .jar file should always be the same...

[PLUCKYHD]

I am seeing this allot lately as well. Has anyone bugged it with sagetv? It is really annoying lately.

Also sagex guys helps not having to constantly deploy since you can test right in your IDE

[Fonceur]

Originally Posted by PLUCKYHD

I am seeing this allot lately as well. Has anyone bugged it with sagetv?

I did back in October, the reply I got was:

Originally Posted by SageTV BetaTest

We have no other reports of this problem, and it works properly in our testing. The only way we know of where it won't work properly is if you are also running SageTVClient on the same system as SageTV and that instance of SageTVClient is connected to a server on another machine. Are you able to reproduce the problem below?

I didn't really follow up, as there wasn't much I could do besides what I said in the bug report...

[joshuad156]

Originally Posted by PLUCKYHD

I am seeing this allot lately as well. Has anyone bugged it with sagetv? It is really annoying lately.

I haven't posted a bug report regarding this yet as I wasn't sure if I was doing something wrong or if this was in fact being seen by the developer community at large.

Originally Posted by PLUCKYHD

Also sagex guys helps not having to constantly deploy since you can test right in your IDE

Now I know I read a post somewhere about this neat trick sometime over the weekend, but my search-fu seems to be failing me. Any chance you can throw me a bone to help find this information?

[PLUCKYHD]

Originally Posted by joshuad156

I haven't posted a bug report regarding this yet as I wasn't sure if I was doing something wrong or if this was in fact being seen by the developer community at large.




Now I know I read a post somewhere about this neat trick sometime over the weekend, but my search-fu seems to be failing me. Any chance you can throw me a bone to help find this information?

See the thread below this one . Remote Apis or read this nice writeup stuckless did about a week ago.

http://forums.sagetv.com/forums/showthread.php?t=536

If you are just deploying to check your code against sage databse this is a must and will save you hours.

[joshuad156]

Originally Posted by PLUCKYHD

http://forums.sagetv.com/forums/showthread.php?t=536

Looks like you linked the wrong post (copy/paste snafu?) However, knowing the author and approx time of the writeup I was able to find this now myself, THANKS! And yes I KNEW I read this a few days ago but couldn't remember where it was.

http://forums.sagetv.com/forums/showthread.php?t=53657

The good news is I'm already using Sagex for my API calls, so this should be SIMPLE to implement. Thanks for the tip! Although it still doesn't solve my plugin restart issue.

[jreichen]

Now that I think about it this might be the cause of a number of problems reported by users of Jetty lately. Users have problems after upgrading and a restart won't help. They report that after they uninstall and reinstall all their plugins everything finally works again.

[PLUCKYHD]

Originally Posted by jreichen

Now that I think about it this might be the cause of a number of problems reported by users of Jetty lately. Users have problems after upgrading and a restart won't help. They report that after they uninstall and reinstall all their plugins everything finally works again.

Yeah I am seeing it allot today in testing I will try and get a log to sagetv if you guys will as well.

[joshuad156]

So I submitted a bug report, and support gave me some things to look for. Here is what I found.

1) Only happens when you run SageTV server in service mode, and connect using a local SageTV client. Extenders and remote clients don't exhibit this problem. (has to do with shared Program Files between the service and the client)

2) When the plugin manager determines the jar file needs to be updated, it stages the update operation via 2 files in the SageTV folder, stageddeletes.txt and stagedrenames.txt. The plugin manager then restarts both the service and the client, however I believe the client prevents the server from executing the delete/rename operation.

2) By closing the client and manually restarting the service, this situation will be resolved.

3) The worst part of this is that the Plugin Manager doesn't seem to validate that the jar replacement occurs as intended. This means that the user becomes completely unaware that the jar file is still waiting to be replaced. Before the plugin manager restarts, it marks the plugin as failed due to the jar needing replaced. But after a restart, SageTV doesn't seem to do any checking to validate that the change occurs before allowing the plugin to start back up.

------

I supplied this info to Sage Support and I really hope that they take it seriously and either make the auto restart work properly (I hope this is what they do) or they at the very least put in some checks to validate the proper jar is running (probably should be done regardless!).

[Savage1701]

Would closing a client also mean a cold power-down of an extender, not just a soft-off from the remote?

That might be an issue for me; my clients are not always on, but my HD-200 is.

I do not, however, run Sage Server v7 in Service mode; I run it as an application.

[joshuad156]

Originally Posted by Savage1701

Would closing a client also mean a cold power-down of an extender, not just a soft-off from the remote?

I believe all extenders disconnect from the server when turned off via the power button on the remote. Also, restarting the server puts any connected extenders into the same standby state. The extenders don't seem to cause this issue (on or off). Only seems relevant when you run the Sage application on the same computer that you are running the Sage service.

[Savage1701]

Joshua:

Since I only run Sage Server v7 as a program/application, not as a service, is there anything I can try?

[joshuad156]

Originally Posted by Savage1701

Joshua:

Since I only run Sage Server v7 as a program/application, not as a service, is there anything I can try?

If you're experiencing these symptoms, I believe you are probably seeing something different than I have documented here. Your scenario doesn't fit what I've experienced.

-----

On a positive note, Sage Support was able to locate the issue and fix the problem. Hopefully we get an updated package before too long.