Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 4 5 [6] 7
  ignore  |  Print  
  JGF v3 - status  (Read 37030 times)
0 Members and 1 Guest are viewing this topic.
Offline EgonOlsen
« Reply #150 - Posted 2005-05-10 20:44:56 »

After claiming that "nothing works" in JGF in the "other" thread (i.e. snake...), i decided that it's unfair to say that without trying it hard enough. So i decided to upload Paradroidz to JGF...the result is: The site is down ATM...i'm really sorry for that.
Anyway...here's what happened: At first, everything went fine, except that lwjgl.jar and lwjgl_util.jar appeared multiple times in the list and the loading indicator of webstart reflected this (i.e. after loading a 300KB jar, it jumped from 3mb loaded to 4mb loaded). It worked fine at the first time except that i made a mistake in the JVM's mx-setting. I adjusted it, deleted everything from webstart, tried again and it told me something about lwjgl-win.zip not being signed correctly (worked fine before). I tried again and it told me, it couldn't load lwjgl_util.jar. I deleted that one, uploaded it again and it told me, that it couldn't load the resource <forgot name>.jnlp
After that, it was gone....and still is. I'm sorry for obviously killing your server, but JGF is just not usable ATM IMHO. How about letting people like me (who want to host their stuff themselves) offering the option to upload a description, some screenshots and a link to the actual game and exclude all the jars from the process. It would save you and me some work and your server some load and trouble.

BTW: Feel free to delete anything related to Paradroidz from the server...

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #151 - Posted 2005-05-10 21:29:55 »

Quote
The site is down ATM...i'm really sorry for that.


The oft-mentioned Direct Buffers memory leak I've been going on about for ages and said twice today I'm working on at the moment Sad. Clearly, it's a simple memory leak in that it happens sooner the more people are using the site Grin.

Quote

appeared multiple times in the list


Documented on the previous page of htis thread

Quote

tried again and it told me something about lwjgl-win.zip not being signed correctly (worked fine before). I tried again and it told me, it couldn't load lwjgl_util.jar. I deleted that one, uploaded it again and it told me, that it couldn't load the resource <forgot name>.jnlp


Unfortunately I can't do anything with those comments just because of the inadequacy of webstart's error-reporting: unless you carefully inspect the JNLP file AND read the exception stack trace AND know what particular stack traces "actually" mean (remembering that they are often thrown in misleading places by webstart), it's impossible to know what the actual error was.

Incidentally, all those errors are symptomatic of you doing something silly with your JARs (I'm not saying you did, I'm saying that I've seen them often and mostly they are author errors. Even done one of them myself quite often Sad : ( ).

Quote

I'm sorry for obviously killing your server,


Nah, not your fault Wink. Three things to note:
- this never ever ever happens on the test server no matter how heavily I load it
- it happens simply by using the server (seems to be just visiting the site that triggers it!). It is *possible* it's some broken library on the server itself (I didn't install it manually, so it's not identical to my test server). Equally, it's possible it's a rootkit for Apache (failing, of course) or some other linux service that as a coincidental side-effect triggers a memory leak in some code - this would explain why it never happens on the test site (not net connected!)
- until recently, it only happened once a week or so. The increased usage of the site has lead to it happeneind once or twice a day (!) this week.

Quote

but JGF is just not usable ATM IMHO.


c.f. the above; mainly I wrote that all out to illustrate (and explain why) it has just got so much WORSE in the last couple of weeks. I wouldn't have asked anyone to try it if it had been crashing once a day. Nor would I even have made it live. It's ... embarassing ... but also very frustrating, knowing that it could be some small, simple, bug.

Fundamentally, there's always something broken or missing, simply because getting it all to work is a massive job that I'm currently doing entirely on my own entirely in my small amount of free time. But it's almost there, and when it *has* worked, it's been wonderful. So I'm confident you'll feel it's all worth it in the end Smiley.

And, besides, when I at last say "there, it's done" and switch off the old site, you'll know for sure that it's been VERY extensively tested Wink. The altenative, I guess, would have been to keep it hidden and invisible all this time, not to tell anyone about it, and eventually release it one day with lots of bugs that simply hadn't yet been noticed because it had never had "in the wild" testing.

Quote

How about letting people like me (who want to host their stuff themselves) offering the option to upload a description, some


You already can do all that, it was expressly designed to do that, EXCEPT that "re-write the HTML for the game page" is on my todo list, and it currently doesn't display the webpage link Angry so it's theoretically possible but not actually doable by you right now. However, c.f. below.

Quote

and exclude all the jars from the process. It would save you and me some work and your server some load and trouble.


No game can fully (*) be listed on JGF unless it has JAR's on the site. This is not negotiable: with just a mere 50 games on the previous version, approximately 5 to 10 were "missing" at any one time, with broken links, broken images, or most often broken downloads. It looks really crap and it makes the rest of the games look bad by association. It drew a huge amount of negative criticism. Sorry, but I'm not going there again.

Especially since it's such a small and painless thing *assuming* the site is working properly (my job). Yes, the site is not yet finished - that's why I've been asking people gradually to try it, add more games bit by bit, see if doing so breaks anything new. Each time everything important seems fixed, I've been coming back and asking for more people to try breaking it.

(*) i.e. ultimately, it's not going to appear in the main games list, it will only be able to appear in an "unreleased games" section.

Quote

BTW: Feel free to delete anything related to Paradroidz from the server...


Thanks for having a go. Although I'd appreciate it if you'd have another go in the future whenever it is I believe I've fixed those few of your problems where I have enough detail to work on.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #152 - Posted 2005-05-10 21:38:27 »

PS: why is Sun's webstart client so ********? Just keeps giving me a world of pain. Howabout this:

"An error occurred while launching/running the application.

Category: Launch File Error

The following required field is missing from the launch file: <jnlp>(<application-desc>|<applet-desc>|<installer-desc>|<component-desc>)"

JNLP:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
<?xml version="1.0" encoding="utf-8"?>
<jnlp
 spec="1.0+"
 codebase="http://javagamesfactory.org/attachments/game/NanoBlaster"
 href="http://javagamesfactory.org/jnlp/NanoBlaster/alpha.jnlp"
 >
      <!-- Last-Modified header will be set to: Tue, 10 May 2005 21:34:17 +0200 -->
      <information>
            <title>NanoBlaster</title>
            <vendor>Author: MasterOfDisaster</vendor>
            <homepage href="$library.webpage" />
            <description kind="one-line" >2D Action Ball game</description>
            <description kind="short" ><p>
Every player tries to hit the other player's goal (surprise surprise!).
The game'
s over when one player has shot 11 goals or if the time limit is over.
During gameplay gimmicks pop up which can be collected and used to annoy the opponent player.
Available modes are Human vs Human, Human vs CPU and CPU vs CPU.
For more details check out <a href="http://games.rastaduck.org/NanoBlaster/">the NanoBlaster home page</a>
</p></description>
            <icon href="game-logo.jpg" />
            <offline-allowed/>
            <jgf-release-type>alpha</jgf-release-type>
            <jgf-release-version>1</jgf-release-version>
      </information>
      <security>
            <all-permissions/>
      </security>
      <resources>
      </resources>
      <resources>
            <jar href="alpha/1/nb.jar" />
            <jar href="alpha/1/images.jar" />
            <jar href="alpha/1/sounds.jar" />
            <jar href="alpha/1/gagetimer.jar" />
      </resources>
      <resources os="Windows">
            <nativelib href="alpha/1/gagetimer-native.jar" />
      </resources>
      <resources>
            <j2se href="http://java.sun.com/products/autodl/j2se" version="1.4.2+" />
      </resources>
      <application-desc>
      </application-desc>
      </jnlp>


Angry In case you're wondering, I checked with an XML editor (in case my eyes deceived me!) and, yes, that application-desc element is where it appears to be. Webstart is just ... lieing.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline EgonOlsen
« Reply #153 - Posted 2005-05-11 03:43:48 »

Quote
Unfortunately I can't do anything with those comments just because of the inadequacy of webstart's error-reporting: unless you carefully inspect the JNLP file AND read the exception stack trace AND know what particular stack traces "actually" mean (remembering that they are often thrown in misleading places by webstart), it's impossible to know what the actual error was.

Incidentally, all those errors are symptomatic of you doing something silly with your JARs (I'm not saying you did, I'm saying that I've seen them often and mostly they are author errors. Even done one of them myself quite often Sad : ( ).
I'm not aware of doing anything wrong with the Jars. They do work when loaded from my own server and they did work the first time i uploaded them to JGF. The actual exception was (sorry for not saving the stack trace), that webstart claimed that the file was in use and therefor, it couldn't access it. But i've cleared the webstart cache, rebooted and re-downloaded the file....i don't see how it could be "in use" by someone else (who, if not webstart itself...?)

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #154 - Posted 2005-05-11 06:53:03 »

Quote

i don't see how it could be "in use" by someone else (who, if not webstart itself...?)


Likewise I couldn't see how the JNLP file could be "not found", or how the 100% obvious, in-your-face, application-desc could be "not found". Webstart's error reporting is just really bad AFAICS Sad

malloc will be first against the wall when the revolution comes...
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #155 - Posted 2005-05-11 11:05:11 »

blah3,

as I see the situation right now, JGF as has been unstable for months and it seems to be due to a lot of webstart bugs and maybe you being too tired because of too long hours. What about give up with the current upload process and simply let the authors upload their jars with their own .jnlp file so that they could manage their own space for their content. For example, when I'd like to create a new game, I would be given an ftp access which allows me to manage the files and directories I need to put my jars and let my .jnlp file works with my game setup. The current game presentation (description, images, etc.) already works fine so I think you don't have to change it.

This solution needs to be more elaborated but I think that you get the idea.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #156 - Posted 2005-05-11 15:26:28 »

Quote
blah3,

What about give up with the current upload process and simply


Unfortunately I can't see how what you describe fixes or side-steps any of the current bugs? I think there may be some misunderstanding here about what the problems are. For instance, the JNLP system has for a long time worked perfectly with no known bugs - although I updated it this weekend with support for libraries/extensions and that may have damaged it in some way; I can't be sure yet - it worked for me every time I tested it.

There have been repeated problems with the uploads (for instance, when it didn't handle files uploaded from a remote-mounted window network drive that was using the SMB naming protocol because SMB has naming conventions that screwed up the parser! Not exactly an obvious thing for me to test against Sad ).

I've also just discovered the cause of one of the bugs above, and it's Sun's webstart client being pants again Sad.


let the authors upload their jars with their own .jnlp file so that they could manage their own space for their content. For example, when I'd like to create a new game, I would be given an ftp access which allows me to manage the files and directories I need to put my jars and let my .jnlp file works with my game setup. The current game presentation (description, images, etc.) already works fine so I think you don't have to change it.

This solution needs to be more elaborated but I think that you get the idea.[/quote]

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #157 - Posted 2005-05-11 15:35:00 »

Quote
PS: why is Sun's webstart client so ********? Just keeps giving me a world of pain. Howabout this:

"The following required field is missing from the launch file: <jnlp>(<application-desc>|<applet-desc>|<installer-desc>|<component-desc>)""


Complete and utter lie. What you actually meant to say, you stupid error handler you Tongue, is:

"According to the JNLP spec, the description field will not render HTML. Most HTML is simply ignored because our implementation was to just ignore any sub-tags and simply render the CDATA picked up in the root tag. However, if you insert an A HREF link in the description then you destroy our parser. Somehow. Please remove the HTML from the description field".

1  
2  
3  
            <description kind="short" ><p>
For more details check out <a href="http://games.rastaduck.org/NanoBlaster/">the NanoBlaster home page</a>
</p></description>


The mind boggles what kind of parsing they're doing; it's only trivial XML (didn't include any ampersand directives etc). I wonder how you could incorrectly parse that in such a way if you're using any of the built-in XML parsers (DOM and SAX)?

It's difficulties like this that force me to struggle on: the average games developer has no chance against the maze of pit-traps in the webstart system. But by discovering, understanding, and permanently fixing these I can save everyone else so much wasted time and effort. For instance, now I know this I can alter the JNLP service to do a character-strip operation on the description field. And probably disallow HTML in the initial description editing interface anyway (is a one-line change of code, literally pass "true" to the "stripHTML" field of the parse method!).

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 164
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #158 - Posted 2005-05-11 15:47:07 »

Eh! Hold on, you can't bung random XML (HTML) into any XML dialect anywhere unless you start using namespaces and schema references?

EDIT: Agreed, that error message is appauling.

Kev

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #159 - Posted 2005-05-11 16:15:13 »

Quote
Unfortunately I can't see how what you describe fixes or side-steps any of the current bugs? I think there may be some misunderstanding here about what the problems are. For instance, the JNLP system has for a long time worked perfectly with no known bugs - although I updated it this weekend with support for libraries/extensions and that may have damaged it in some way; I can't be sure yet - it worked for me every time I tested it.

There have been repeated problems with the uploads...

I tought there are bugs related to webstart since many games fail to start because of a webstart problem. When you try all of these games outside the JGF scope, they run without problem so why when someone try one from JGF, it fails with a webstart exception? And I don't talk about the jar versionning problems here. I mean, if you let the authors put their content as is with security and versionning checks enforced (alpha versus beta and prod) then there is no reason a game would not work properly if it worked previously from the author's website.

If I didn't catch all the issues please tell me what it is. I just want to help you.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #160 - Posted 2005-05-12 21:12:14 »

Most of the webstart problems are fixed by trying "outside" JGF for reasons less obvious than you think. For instance, if you load a JNLP from your hard disk you completely bypass MSIE. For instance, if you load a JNLP that is 100% broken BUT it is working just enough for webstart to pick the HREF out of the jnlp tag then it will IGNORE your jnlp and use the one it sees online, etc etc. There are many many issues that make it very hard to test and debug webstart issues at the webstart client, including of course all the problems to do with the fact that the webstart client is running your app in a rather funky and bizarre manner.

Anyway, tonight I ran 3 hours of stress tests over my LAN against the server, and found some interesting issues.

1. every page that uses templates is 4 times slower than pages that do not, even though the latter use 4 or 5 NONCACHED MySQL queries each (read: makes them very slow). Velocity is terrifyingly slow as a caching template system, and we may have to dump it (it's also full of horrendous bugs, as almost everyone has seen by now)

2. there is what appears to be a race condition somewhere in the system. It triggers entirely randomly, anywhere from 161 requests into the run up to 15,000 requests into the run. It causes the JVM to hang completely with no exceptions, no errors, and no CPU usage. Hence I suspect it's a deadlock, although I have no idea whether it's my code, grexengine code, or the base libraries I'm using. This could be very painful indeed to track down.

3. I believe I've worked around the main cause of the frequently recurring outofmemory error by implementing my own memory manager to manage bytebuffers. I am unhappy that Sun didn't provide any memory management support for NIO *at all* and that I'm back to digging out old C textbooks to refresh how to do memory management effectively.

However, I noticed in passing that there are many places in user code that are creating implicit bytebuffers. Because Sun have no support for mem management and appear to have flaws if not outright bugs in their garbage-collection of these things this "feature" is potentially a disaster waiting to happen. With my memory-management layer I should be able to conclusively decide if any future OOME was because of my manual BB's or the implicit BB's (it catches OOME and dumps the full status of every known buffer so I can manually verify whether it really should have "run out"). If the latter, then java.nio.* is, in a word, buggered. I very much hope that whatever was causing the OOME turns out only to be some bug (JVM, libraries, or me abusing them by accident) that affects explicit BB's.

I've patched the main server, and now I'm just waiting to see what happens.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #161 - Posted 2005-05-12 21:15:34 »

I've also made the JNLP creation code a lot more fascist: it will go through all the fields handed to it and strip HTML. Where it finds P tags it will automatically pull out the contents of the first paragraph and only use them. This makes the "nanoblaster" game currently on JGF finally work (because it strips out the A HREF that was crashing Sun's crummy parser) - but, sadly, that game's author wrote it so that it crashes if it fails to initialise sound (*), and so it wouldn't run on the soundless machine I tried it on Sad. But at least it starts Smiley.

(*) a very common problem that IMHO needs to be a FAQ because of the subtlety of it. Very annoying to write games and not realise what happens to machines with e.g. no sound card.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #162 - Posted 2005-05-12 21:19:44 »

Finally, in case it wasn't sufficiently obvious, the image in my SIG here on JGO is dynamically created by the JGF server. If everyone's browsers would render SVG images properly, I'd turn this on for all users, but at the moment so many browsers can't do it that I need to run a post-processor that converts them to JPG's. This massively slows down the server! If I have nothing better to do with my time at some point, I'll work some magic with faked expires times and possibly a small in-memory LRU cache for the JPG's and enable the feature for all users.

The idea is to create a SIG image automatically that keeps updating with things like "how popular my games are" (for authors) and "where I stand on the highscores tables on JGF games" (for games players)

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #163 - Posted 2005-05-12 22:36:29 »

Quote

1  
2  
3  
            <description kind="short" ><p>
For more details check out <a href="http://games.rastaduck.org/NanoBlaster/">the NanoBlaster home page</a>
</p></description>


The mind boggles what kind of parsing they're doing; it's only trivial XML (didn't include any ampersand directives etc). I wonder how you could incorrectly parse that in such a way if you're using any of the built-in XML parsers (DOM and SAX)?


The thing that comes to mind is that the description element you have there doesn't have a single text node at all. It only has an HTML paragraph element.  I don't know if that is related to the problem, but as kevglass indicated, you can't just go and put HTML wherever you want inside an XML document.  Unless it said in the JNLP spec that HTML is allowed...  (I didn't check, but have assumed that it wasn't allowed)

Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #164 - Posted 2005-05-12 23:09:49 »

Quote
Finally, in case it wasn't sufficiently obvious, the image in my SIG here on JGO is dynamically created by the JGF server.


That's really cool,  almost cool enough to motivate me to finish a game to get it in my jgf jpg.....   Shocked
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #165 - Posted 2005-05-13 06:19:57 »

Quote

The thing that comes to mind is that the description element you have there doesn't have a single text node at all. It only has an HTML paragraph element.

One of the laziest ways to parse XML (if using SAX) would simply pick up all text in all subnodes as a by-product. Shrug. I'm not saying it should be done like that, but in many cases in people's programs it does work because they decided to just ignore any tags inside tag X and just pick up all the text that was there. This used to be more common than it is now, possibly because more people use DOM Roll Eyes.

Quote

I don't know if that is related to the problem, but as kevglass indicated, you can't just go and put HTML wherever you want inside an XML document.  Unless it said in the JNLP spec that HTML is allowed...  (I didn't check, but have assumed that it wasn't allowed)


Sigh. I knew from the start it was not meant to be HTML, but I also knew that XML parsers would cope with it without crashing so long as it was well-formed XML. AFAIAA (maybe I'm missing somethhing here?) if you use an XML parser properly it shouldn't crash in this kind of scenario; unexpected tags within a tag you are reading will not affect you (your code simply won't access them). It's one of the advantages of XML: it's robustness in the face of not-quite-right input.

The spec doesn't say what will happen, only that it may not be HTML (IIRC the word is "may" and not "must"). So I tried it to see if it would pick up the text (it didn't, fair enough - that's a perfectly valid way to deal with it) and then it went onto my todo list to strip the HTML tags, somewhere around the middle. The fact that you're only supposed to have one paragraph meant I would also need to put in logic to pick up just one paragraph.

In almost all cases, it's no problem, it just means it has no description. But in this one case it kills the webstart client, and I'm still at a loss as to why/how. And, as we've seen, the error message is completely wrong (typical with Sun's webstart client: IIRC I've not yet seen an error message that was 100% correct apart from the "the jars aren't signed" one).

So...I'm not trying to defend the use of HTML in that tag, but I object to the awful error handling in the webstart client, and I am surprised that it caused any problem at all, let alone a "fatal" one Sad.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #166 - Posted 2005-05-13 06:26:48 »

Quote


That's really cool,  almost cool enough to motivate me to finish a game to get it in my jgf jpg.....   Shocked


Grin *everything* in there is generated algorithmically, apart from the cog image itself. It was a bitch to get circular text, but I got it in the end Wink, and even though it looks a bit "first steps with WordArt" it was just a proof of concept.

The big question now is: What should go in there? Anything is possible. Suggestions are welcome, and I'll probably put a small form up in your profile page where you can pick e.g. 3 stats in particular to have in your image.

malloc will be first against the wall when the revolution comes...
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #167 - Posted 2005-05-13 10:01:27 »

Quote
Hence I suspect it's a deadlock, although I have no idea whether it's my code, grexengine code, or the base libraries I'm using. This could be very painful indeed to track down.


<naivety>At least on linux, hitting ctrl-\ prints a thread dump and identifies deadlocks</naivety>
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #168 - Posted 2005-05-13 10:05:03 »

what ever u did to JGF for some reason its way cooler now!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #169 - Posted 2005-05-16 05:00:28 »

Quote


<naivety>At least on linux, hitting ctrl-\ prints a thread dump and identifies deadlocks</naivety>


Thanks for the tip Wink. Sadly, since this is a *server*, the app runs as a background service (using the start/stop daemon) and I've no idea how you could send particular characters direct to the input stream. I also strongly suspect all output would disappear - the standard logging libraries only log log messages, not stdout and stderr.

(I'm sure if I spend a while digging in manpages I could find a way to re-route stuff to/from the daemon, but it's just not trivial)

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #170 - Posted 2005-05-16 05:11:27 »

Quote
what ever u did to JGF for some reason its way cooler now!


Thanks. While Chris was slaving over the forums here, I was slaving over webstart-extensions, bugs in Sun's webstart client, and cleaning-up the game templates.

You can see here: http://javagamesfactory.org/views/view-game?name=Survivor a taste of what the other games will be like, with their libraries shown at the bottom of the screen (note: this is all handled automatically, of course Wink).

You may also notice that there's a spot for each author to include a small photo of themself Smiley ... but it'll be a while before I have time to add the DB table etc to store them.

Unfortunately, a super huge bug in webstart means that anyone who accessed JGF in the last few days has a high chance of having picked up JNLP files that *crash the JGF server*.

As far as I know there is *nothing* I can do about this: it's a horrid, horrid bug in the webstart client *AND* because of the other bug in the client (the one where it caches broken JNLP's indefinitely) it is not possible to get a new, working, JNLP to any of these people.

I don't know; maybe I will just have to trace their IP addresses, and then post them, and ask anyone who recognires themself to delete their webstart cache. Until they do, they are submitting illegal HTTP requests to the server and causing a DoS attack Angry.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #171 - Posted 2005-05-16 05:21:23 »

Quote


Thanks. While Chris was slaving over the forums here, I was slaving over webstart-extensions, bugs in Sun's webstart client, and cleaning-up the game templates.

You can see here: http://javagamesfactory.org/views/view-game?name=Survivor a taste of what the other games will be like, with their libraries shown at the bottom of the screen (note: this is all handled automatically, of course Wink).

You may also notice that there's a spot for each author to include a small photo of themself Smiley ... but it'll be a while before I have time to add the DB table etc to store them.

Unfortunately, a super huge bug in webstart means that anyone who accessed JGF in the last few days has a high chance of having picked up JNLP files that *crash the JGF server*.

As far as I know there is *nothing* I can do about this: it's a horrid, horrid bug in the webstart client *AND* because of the other bug in the client (the one where it caches broken JNLP's indefinitely) it is not possible to get a new, working, JNLP to any of these people.

I don't know; maybe I will just have to trace their IP addresses, and then post them, and ask anyone who recognires themself to delete their webstart cache. Until they do, they are submitting illegal HTTP requests to the server and causing a DoS attack Angry.


EDIT: I remembered that other grexengine servers witnessed deliberate attacks like this a couple of years ago. There is something I can do about this; the base grexengine server is immune to these corrupt HTTP attacks, so it's obviously something in my forked parser that's broken. Once I've fixed my parser, the DoS should go away (for some reason, the broken requests are damaging any genuine requests that come in on different sockets at the same time; I have no idea how this is even possible, since there's no shared data - it's all done with ThreadLocal objects etc). But the people with broken copies of JGF games will find that they never work again, AFAIAA Sad

malloc will be first against the wall when the revolution comes...
Offline maxcaleb

Senior Newbie




Say car Ramrod!!


« Reply #172 - Posted 2005-05-16 23:42:00 »

Quote


Thanks for the tip Wink. Sadly, since this is a *server*, the app runs as a background service (using the start/stop daemon) and I've no idea how you could send particular characters direct to the input stream. I also strongly suspect all output would disappear - the standard logging libraries only log log messages, not stdout and stderr.

(I'm sure if I spend a while digging in manpages I could find a way to re-route stuff to/from the daemon, but it's just not trivial)


Not sure how possible this is with your current setup, but JDK 1.5 includes some new profiling/analysis tools including jstack, which will perform the same function as
ctrl-\, except you can attach it to an arbitrary pid.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #173 - Posted 2005-07-31 00:18:32 »

Update...

1. All work on JGF halted whilst trying to prove + demonstrate to Sun the recently discovered *probable* NIO bug where it drops characters. I haven't heard back from them in many weeks, and I don't have time to wait for a response that may never come; I've now given up on running JGF over NIO.

2. Given that JGF runs on a web-application that runs on the GrexEngine, and the GrexEngine is a Service-Oriented Architecture / platform for hosting any kind of server, it's not all that dissimilar from a servlet running on J2EE. Today I created a handful of GrexEngine wrapper classes that enable me to embed the entire app within a J2EE-compatible container, and have the J2EE container *only* handle the HTTP requests ***

3. As of this evening, the basic website is working (generating pages dynamically and outputing them to web browser), so things are going well. It's only taken a couple of hours, and I hope to have the whole thing working again within a matter of days, depending on my free time.

4. Hopefully...with NIO out of the way, and if the bug really *is* from NIO, and not my code, JGF should be "fixed" very soon. I'm hoping it will also turn out that NIO or my HTTP parser was the cause of some of the stability problems, so that it will be more stable from now on. Performance will probably suffer a little, but the container is very fast and I doubt anyone will notice the difference!

*** - to anyone who's interested, none of the crap of WAR's etc is pulled in to contaminate things: the system is still managed by the GrexEngine, and its dynamic config and clustering system etc, it's just that for HTTP (where NIO is *apparently* corrupting my channels) the J2EE container is an additional module that can generate and complete incoming requests and their responses.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #174 - Posted 2005-07-31 13:06:34 »

It's amazing how you can take 12 months to code a simple dynamic website in Java which would take Chaz about 2 weeks in PHP with Mysql eh?

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #175 - Posted 2005-07-31 13:37:06 »

It's amazing how you can take 12 months to code a simple dynamic website in Java which would take Chaz about 2 weeks in PHP with Mysql eh?

Thanks for the vote of confidence, you sarky git Sad.

The vast majority of the time spent so far has been things that would have taken just as long if done in PHP - e,g,:
  • working through the intracacies of the webstart protocol
  • GUI design and improvement (making the admin controls easy to use just as much as the visual layout)
  • working through the intracacies of HTTP and CSS (in)compatibility
  • security controls, given how much of the site is admined on-line directly
  • modules for: library comparison and maintenance, article suggestion and editing, game-submission and editing, etc
  • ...etc

...and if it's so easy, why hasn't everyone else done all that? How many JNLP-creators have YOU seen, for instance? I've seen a couple of partial ones, but none that did everything I wanted (...and, assuming the site is working again in a week or so, I can go back to finishing my final webstart creator that uses the version protocol)

In comparison a relatively small amount of time has gone on things like me breaking the HTTP parser, and making high-performance file upload and download that isn't going to crash the server when a dozen or more people try to upload 20 Mb of JARs at the same time. When it got to the point where I had a bug in NIO I couldn't seem to workaround, I took the cop-out approach and plugged-in Jetty (although I had to wait > 1 month to give the Sun engineer time to look at the server).

BTW: the problem with the trivial LAMP approach is that it completely breaks when the site becomes popular. You then have to spend an extra 6 months (or, look at gamedev.net - they spent upwards of 18 months with a broken site at this point. Or look at flipcode - 18+ months again to fix) to fix the thing, meanwhile your once-popular site is getting slagged off for getting worse and worse every day.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #176 - Posted 2005-07-31 14:35:10 »

Quote
How many JNLP-creators have YOU seen, for instance?
LOL! One, as it happens. I hired a guy a few weeks ago and his first day on the job he whipped on up for our Webstart deployed app in PHP inside 30 minutes. (Each customer needs a custom jnlp file).

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #177 - Posted 2005-07-31 14:47:06 »

LOL! One, as it happens. I hired a guy a few weeks ago and his first day on the job he whipped on up for our Webstart deployed app in PHP inside 30 minutes. (Each customer needs a custom jnlp file).

Even someone who's never written java code before could probably "whip up" a JNLP creator that made some trivial JNLP's with a tiny amount of customization. That's not the same as supporting the entire gamut of the JNLP spec, with arbitrary input data at every point - it takes around 30 minutes just to actually *read* the entire spec. Shrug.

Anyway, everything now appears to be working bar file-uploads (which is simply because I haven't ported them to J2EE old-I/O yet).

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #178 - Posted 2005-07-31 15:12:08 »

Anyway, everything now appears to be working bar file-uploads (which is simply because I haven't ported them to J2EE old-I/O yet).

So any idea of an expected launch date? I might have to get off my arse and try and get this little shooty game up to a playable state for it...

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline woogley
« Reply #179 - Posted 2005-07-31 18:00:34 »

...and if it's so easy, why hasn't everyone else done all that?

in about 3 months time I did Java Unlimited.. though it doesnt have a JNLP generator (nor does it need one), but the full admin panel / game submitting / commenting etc is all there. I orignally was going to do it with Java but PHP was less bulky and easier to use (no driver loading in the actual code just to do a quick DB call, for example). Prior to Java Unlimited I didn't know hardly any PHP, so it was also my way of learning it.

I'm not saying throw away all of your JGF code, but you might want to weigh your coding options a bit. So far I havent had any I/O problems (or any other unexplainable bugs) with PHP.

IMO, Java is better suited for programs.. not webpages. But hey, just an opinion. Lips Sealed
Pages: 1 ... 4 5 [6] 7
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (28 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (72 views)
2014-09-10 06:39:09

Tekkerue (37 views)
2014-09-09 02:24:56

mitcheeb (57 views)
2014-09-08 06:06:29

BurntPizza (43 views)
2014-09-07 01:13:42

Longarmx (27 views)
2014-09-07 01:12:14

Longarmx (34 views)
2014-09-07 01:11:22

Longarmx (34 views)
2014-09-07 01:10:19

mitcheeb (40 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!