[Gzz-commits] storm/doc/pegboard/storm_with_tapestry--hemppah...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Branch:         
Changes by:     Hermanni Hyytiälä <address@hidden>      03/07/09 06:18:23

Modified files:
        doc/pegboard/storm_with_tapestry--hemppah: peg.rst 

Log message:
        (perhaps) new major issue

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/storm_with_tapestry--hemppah/peg.rst.diff?tr1=1.20&tr2=1.21&r1=text&r2=text

Patches:
Index: storm/doc/pegboard/storm_with_tapestry--hemppah/peg.rst
diff -u storm/doc/pegboard/storm_with_tapestry--hemppah/peg.rst:1.20 
storm/doc/pegboard/storm_with_tapestry--hemppah/peg.rst:1.21
--- storm/doc/pegboard/storm_with_tapestry--hemppah/peg.rst:1.20        Tue Jul 
 8 08:43:15 2003
+++ storm/doc/pegboard/storm_with_tapestry--hemppah/peg.rst     Wed Jul  9 
06:18:23 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-07-03
-:Last-Modified: $Date: 2003/07/08 12:43:15 $
-:Revision: $Revision: 1.20 $
+:Last-Modified: $Date: 2003/07/09 10:18:23 $
+:Revision: $Revision: 1.21 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -45,12 +45,46 @@
        Tapestry related java class names will reference.
               
 
-ISSUE:  Does Storm use threads in the current implementation? The issue with
-        this is that Sandstorm Tutorial (included with the SEDA release)
+ISSUE:  Does Storm use native Java threads in the current implementation? The 
+       issue with this may be that Sandstorm Tutorial (included with the SEDA 
release)
        says "Don't allocate or manage threads in your application".
        
-.. will check this.
+SOLVED:        The current implementation of Storm uses native Java threads in 
the 
+       following classes:
+       
+       org/nongnu/storm/util/HTTPProxy.java
+       org/nongnu/storm/http/server/HTTPServer.java
+       org/nongnu/storm/http/server/HTTPConnection.java
+       org/nongnu/storm/impl/p2p/Peer.java
+       org/nongnu/storm/modules/gispmap/GispP2PMap.java
+       org/nongnu/storm/modules/gispmap/GispPeer.java
+       
+       The first three classes are used with HTTP-Kit and the three 
+       latter ones with GISP. Obviously, GISP related classes are not a problem
+       as they are obsolete but HTTP-Kit related may be, i.e., classes have to 
+       re-engineer to SEDA compliant classes.
+       
+ISSUE: If a software uses SEDA in one component, is it mandatory to use SEDA's
+       thread-event model in all other components also (i.e. native Java 
threads
+       are not allowed)?
        
+.. I realized this "Don't allocate or manage threads in your application" 
+   (possible) issue while I was reading Sandstorm Tutorial and 
+   User's Guide. This "feature" of SEDA has not been mentioned anywhere in 
Tapestry
+   website, nor Tapestry installation guide, nor Tapestry Programmer's guide,
+   nor Javadocs!
+   
+   If a software cannot use native Java threads as one software
+   component uses SEDA's thread-event model, it's a *major* issue for us. Thus,
+   the choices are:
+   
+   1) Dumb Tapestry (the better choice)
+   2) Re-engineer Fenfire framework to SEDA compliant (a very bad choice)
+   
+   I will investigate this more carefully...
+   
+   
+              
 
 Introduction to Tapestry
 ========================
@@ -331,6 +365,7 @@
                } else if (item instanceof TapestryReadyMsg) {
                        // Connected to network.            
                        publishLocalStormPool()
+                       // do something else, if needed
                } else if (item instanceof TapestryDetachConfirm) {
                        // Disconnected from network.
                        unpublishLocalStormPool()