"Spec Info Unavailable" - Issue

Sep 2, 2009 at 3:16 PM

Hello all :)

I have a Guild Website i'm building on DNN 4.9 and dropped the module on but it seems to pull the characters but none of the info associated with those characters and so all i get is "Spec Info Unavailable" and when viewing a character none of the fiels are populated.

http://enimty.ds5164.dedicated.turbodns.co.uk/roster.aspx

That's the address the roster is on, it does feel like i'm probably missing some obvious setting or option but any help would be appreciated!

Maynards

Sep 4, 2009 at 1:49 AM

Hi maynards,

Your post prompted me to go check my site.  At first everything looked normal, but I checked the module errors and data load log and found this:

http://www.stormspire.com/temp/errorlog.png

Note that the last successful Char data load on my site was 9/2/09 @ 8:59PM. All are still failing. Roster loads still seem to be working.

My guess is that they modified the armory site again.

Mr. developer sir?  When you get off the 4AM feeding roster we could use a hand with this one:P

 

 

Sep 4, 2009 at 2:03 AM

Seeing this made me check my siute as well. I have to say that things seem to be loading fine here.

I checked the scheduler logs and I am showing successes. In fact the last scheduled run finished not 5 minutes ago successfully.

I am using DNN 5.1.0 . Not sure if that would make a difference or not, but if I recall Argonne was using a 4.* version as well.

Food for thought.

Sep 5, 2009 at 3:23 AM

You won't see those errors in the scheduler log. Go into the Guild Roster control panel and take a look at "data loads" and "errors".

Coordinator
Sep 5, 2009 at 7:37 PM

I'll poke around on my site this weekend and see if anything reproducable on my end shows up. :)

Sep 5, 2009 at 11:51 PM
Edited Sep 6, 2009 at 6:41 PM

Sounds good.  I'm backing up my site right now in preparation for upgrading to 4.9.5. If I disappear,  you'll know I screwed it up bad. I'm giving it even odds.

Update:  9/10ths of the way through the ftp upload I had a power bump. I hadn't blocked site access with an app_offline.htm file.  Some user clicked "install". KaBlooey!, site is down and I'm trying to sort it out. Joy, joy....

 

Sep 24, 2009 at 2:36 PM

I've just created a new portal using the module and I can confirm that this info is not updating. Any chance of getting a fix here?

Coordinator
Sep 26, 2009 at 8:43 PM
Edited Sep 26, 2009 at 8:43 PM

Okay - found the issue...It looks like Blizzard changed where the Arena team info was being stored on the server - and the XML requests were returning error 500's.

I fixed the code for general guild members so that it no longer does an XML file query for all arena teams (which should reduce traffic to Armory server by 20-30%). I just need to track down where the arena team info IS, so that this doesn't error out for folks who DO do PvP. :)

As an aside, I also fixed the portraits to use the new URL (looks like Blizzard changed the name of the images folder to _images).

I'll have a package ready and posted by end of day with the fixes.

Coordinator
Sep 27, 2009 at 12:43 AM

Okay - 1.8.5 is posted!

Sep 28, 2009 at 11:53 PM

And....It seems to be working.  Thank you sir.

Sep 29, 2009 at 9:00 PM

perfect! 

I just started to play with GuildRoster, and did hit that "server 500" issue.  Then upgraded to 1.8.5 and now it all works great!

Coordinator
Sep 29, 2009 at 10:14 PM
Edited Sep 29, 2009 at 10:15 PM

Yay for both of you!

Argonne - Are you still on DNN 4.x? Or did you bite the bullet and move to DNN 5?
Fyre - Welcome to the club!

As an aside, I am also thinking about cleaning up the Armory load logic to stop this 20-30 roster reloads per character load. I'm having an issue on my site (and I'm assuming others are having the same) where the character loading takes longer than DNN stays in memory. For me, this yields a very messy 'data loads' list and a DNN event log that is just FLOODED with 'Thread being aborted' exceptions...and I do mean FLOODED. For me, it's to the point where I had to execute SQL to clean out my events log table to get it to truncate.

What I'm thinking is to create a new table that tracks Armory loads, and allows only one roster refresh per character refresh - this should clean things up on that angle. I'm trying not to overengineer this, but I would then have an Armory load which would run...and the scheduled service would key off of that master run, spinning up one roster set of runs and one set of character run. This would mean that the Armory service would then try and pick up the 'current run' and pick up there, spinning up a new one if there is no 'current' run. This would change the current behavior of run a roster update and then refresh characters if prior one didn't finish...which was great in design, but has some issues when the ASP.NET process gets recycled.

Oct 1, 2009 at 7:40 PM
csimpkins wrote:

Yay for both of you!

Argonne - Are you still on DNN 4.x? Or did you bite the bullet and move to DNN 5?

Haven't quite made it to 5.x yet, but recently crept up to 4.9.5.  It didn't exactly go smoothly owing to a power bump in the middle of the upgrade, but the experience was good training. I'm planning on moving to 5.x, but am waiting until an window of time presents itself that will be sufficient to fix everything if it goes badly.

You mentioned DNN unloading.  After trying 4 different keep-alive schemes, I finally found one that works.  It's free, but requires you put a link on your site. Link below:

TMM Services Keep Alive