Menu
▾
▴
bigdata-developers — List for bigdata developers
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
(19) |
Mar
(8) |
Apr
(25) |
May
(16) |
Jun
(77) |
Jul
(131) |
Aug
(76) |
Sep
(30) |
Oct
(7) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
(16) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(7) |
| 2012 |
Jan
(10) |
Feb
(1) |
Mar
(8) |
Apr
(6) |
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(8) |
Dec
(2) |
| 2013 |
Jan
(5) |
Feb
(12) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(22) |
Aug
(50) |
Sep
(31) |
Oct
(64) |
Nov
(83) |
Dec
(28) |
| 2014 |
Jan
(31) |
Feb
(18) |
Mar
(27) |
Apr
(39) |
May
(45) |
Jun
(15) |
Jul
(6) |
Aug
(27) |
Sep
(6) |
Oct
(67) |
Nov
(70) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
(18) |
Mar
(22) |
Apr
(121) |
May
(42) |
Jun
(17) |
Jul
(8) |
Aug
(11) |
Sep
(26) |
Oct
(15) |
Nov
(66) |
Dec
(38) |
| 2016 |
Jan
(14) |
Feb
(59) |
Mar
(28) |
Apr
(44) |
May
(21) |
Jun
(12) |
Jul
(9) |
Aug
(11) |
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2017 |
Jan
(20) |
Feb
(7) |
Mar
(4) |
Apr
(18) |
May
(7) |
Jun
(3) |
Jul
(13) |
Aug
(2) |
Sep
(4) |
Oct
(9) |
Nov
(2) |
Dec
(5) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bryan T. <br...@sy...> - 2014-03-26 15:48:35
|
Try again. There was a jetty import in com.bigdata.rdf.sail.webapp.BigdataRDFServletContextListener that was causing a failure. Committed revision r8017. bryan On 3/26/14 8:42 AM, "Jim Balhoff" <ba...@ne...> wrote: >That line is commented out in my web.xml. From tomcat 7 I have this in >the log: > >SEVERE: Exception sending context initialized event to listener instance >of class com.bigdata.rdf.sail.webapp.BigdataRDFServletContextListener >java.lang.NoClassDefFoundError: org/eclipse/jetty/proxy/ProxyServlet > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:800) > at >java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at >org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClass >Loader.java:2888) > at >org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.j >ava:1172) > at >org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.j >ava:1680) > at >org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.j >ava:1558) > at >com.bigdata.rdf.sail.webapp.BigdataServlet.<clinit>(BigdataServlet.java:80 >) > at >com.bigdata.rdf.sail.webapp.BigdataRDFServletContextListener.contextInitia >lized(BigdataRDFServletContextListener.java:411) > at >org.apache.catalina.core.StandardContext.listenerStart(StandardContext.jav >a:4797) > at >org.apache.catalina.core.StandardContext.startInternal(StandardContext.jav >a:5291) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > at >org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java >:901) > at >org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) > at >org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:111 >4) > at >org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java >:1673) > at >java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: >1145) > at >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java >:615) > at java.lang.Thread.run(Thread.java:744) >Caused by: java.lang.ClassNotFoundException: >org.eclipse.jetty.proxy.ProxyServlet > at >org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.j >ava:1713) > at >org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.j >ava:1558) > ... 22 more > > >On Mar 26, 2014, at 10:32 AM, Bryan Thompson <br...@sy...> wrote: > >> If you uncomment this line in web.xml then it will attempt to resolve >>the >> HALoadBalancerServlet and that would drag in the ProxyServlet. >> >> >> >><servlet-class>com.bigdata.rdf.sail.webapp.HALoadBalancerServlet</servlet >>-c >> lass> >> >> >> >> Bryan >> >> On 3/26/14 8:30 AM, "Bryan Thompson" <br...@sy...> wrote: >> >>> There are several new jars for jetty 9. One of them includes this >>>servlet >>> (jetty-proxy). Make sure that these are in place when using jetty. >>> >>> These jars should not be required for the tomcat war. Can you send the >>> full exception? I'd like to see where the exception is being thrown >>>from. >>> >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-rewrite-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-proxy-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-webapp-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/servlet-api-3.1.0.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-xml-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-io-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-continuation-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-util-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-client-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-security-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-http-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-servlet-9.1.3.v20140225.jar >>> >>>file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib >>>/j >>> e >>> tty/jetty-server-9.1.3.v20140225.jar >>> >>> >>> >>> Bryan >>> >>> On 3/26/14 8:26 AM, "Jim Balhoff" <ba...@ne...> wrote: >>> >>>> I am having trouble running the RDR branch bigdata.war in both tomcat >>>>and >>>> jetty. I get the error: >>>> >>>> java.lang.ClassNotFoundException: org.eclipse.jetty.proxy.ProxyServlet >>>> >>>> Is this something I need to add to my web app container? >>>> >>>> Thank you, >>>> Jim >>>> >>>> On Mar 12, 2014, at 6:52 AM, Bryan Thompson <br...@sy...> wrote: >>>> >>>>> I've fixed the builds in this branch. The problems all go back to >>>>>the >>>>> changes to support configuration of jetty using jetty.xml and >>>>>web.xml. >>>>> >>>>> I am still looking at eliminating the manual configuration of the NSS >>>>> and making code paths rely on web.xml, even for embedded use. I think >>>>> that is will work out and allowing override of the jetty.xml file >>>>> location will provide an option for complete customization. You will >>>>> also be able to override properties in jetty.xml using environment >>>>> variables and init parameters in web.xml using the NSS command line >>>>> options. >>>>> >>>>> Hopefully this will put an end to this aspect of the jetty >>>>>refactoring. >>>>> >>>>> I have added a dependency on the jetty rewrite jar in preparation for >>>>> introducing load balancing into the HA cluster. It looks like we >>>>>can do >>>>> this using the ProxyServlet in jetty. I will also be changing the >>>>> dependencies to jetty 9.1. >>>>> >>>>> Bryan >>>>> >>>>> >>>>>---------------------------------------------------------------------- >>>>>-- >>>>> - >>>>> ----- >>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>> "Graph Databases" is the definitive new guide to graph databases and >>>>> their >>>>> applications. Written by three acclaimed leaders in the field, >>>>> this first edition is now available. Download your free book today! >>>>> http://p.sf.net/sfu/13534_NeoTech >>>>> _______________________________________________ >>>>> Bigdata-developers mailing list >>>>> Big...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/bigdata-developers >>>> >>> >>> >>> >>>------------------------------------------------------------------------ >>>-- >>> ---- >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>>their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/13534_NeoTech >>> _______________________________________________ >>> Bigdata-developers mailing list >>> Big...@li... >>> https://lists.sourceforge.net/lists/listinfo/bigdata-developers >> > |
|
From: Jim B. <ba...@ne...> - 2014-03-26 15:43:01
|
That line is commented out in my web.xml. From tomcat 7 I have this in the log: SEVERE: Exception sending context initialized event to listener instance of class com.bigdata.rdf.sail.webapp.BigdataRDFServletContextListener java.lang.NoClassDefFoundError: org/eclipse/jetty/proxy/ProxyServlet at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2888) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1172) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558) at com.bigdata.rdf.sail.webapp.BigdataServlet.<clinit>(BigdataServlet.java:80) at com.bigdata.rdf.sail.webapp.BigdataRDFServletContextListener.contextInitialized(BigdataRDFServletContextListener.java:411) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4797) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5291) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1114) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1673) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.proxy.ProxyServlet at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1713) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558) ... 22 more On Mar 26, 2014, at 10:32 AM, Bryan Thompson <br...@sy...> wrote: > If you uncomment this line in web.xml then it will attempt to resolve the > HALoadBalancerServlet and that would drag in the ProxyServlet. > > > <servlet-class>com.bigdata.rdf.sail.webapp.HALoadBalancerServlet</servlet-c > lass> > > > > Bryan > > On 3/26/14 8:30 AM, "Bryan Thompson" <br...@sy...> wrote: > >> There are several new jars for jetty 9. One of them includes this servlet >> (jetty-proxy). Make sure that these are in place when using jetty. >> >> These jars should not be required for the tomcat war. Can you send the >> full exception? I'd like to see where the exception is being thrown from. >> >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-rewrite-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-proxy-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-webapp-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/servlet-api-3.1.0.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-xml-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-io-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-continuation-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-util-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-client-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-security-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-http-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-servlet-9.1.3.v20140225.jar >> file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >> e >> tty/jetty-server-9.1.3.v20140225.jar >> >> >> >> Bryan >> >> On 3/26/14 8:26 AM, "Jim Balhoff" <ba...@ne...> wrote: >> >>> I am having trouble running the RDR branch bigdata.war in both tomcat and >>> jetty. I get the error: >>> >>> java.lang.ClassNotFoundException: org.eclipse.jetty.proxy.ProxyServlet >>> >>> Is this something I need to add to my web app container? >>> >>> Thank you, >>> Jim >>> >>> On Mar 12, 2014, at 6:52 AM, Bryan Thompson <br...@sy...> wrote: >>> >>>> I've fixed the builds in this branch. The problems all go back to the >>>> changes to support configuration of jetty using jetty.xml and web.xml. >>>> >>>> I am still looking at eliminating the manual configuration of the NSS >>>> and making code paths rely on web.xml, even for embedded use. I think >>>> that is will work out and allowing override of the jetty.xml file >>>> location will provide an option for complete customization. You will >>>> also be able to override properties in jetty.xml using environment >>>> variables and init parameters in web.xml using the NSS command line >>>> options. >>>> >>>> Hopefully this will put an end to this aspect of the jetty refactoring. >>>> >>>> I have added a dependency on the jetty rewrite jar in preparation for >>>> introducing load balancing into the HA cluster. It looks like we can do >>>> this using the ProxyServlet in jetty. I will also be changing the >>>> dependencies to jetty 9.1. >>>> >>>> Bryan >>>> >>>> ------------------------------------------------------------------------ >>>> - >>>> ----- >>>> Learn Graph Databases - Download FREE O'Reilly Book >>>> "Graph Databases" is the definitive new guide to graph databases and >>>> their >>>> applications. Written by three acclaimed leaders in the field, >>>> this first edition is now available. Download your free book today! >>>> http://p.sf.net/sfu/13534_NeoTech >>>> _______________________________________________ >>>> Bigdata-developers mailing list >>>> Big...@li... >>>> https://lists.sourceforge.net/lists/listinfo/bigdata-developers >>> >> >> >> -------------------------------------------------------------------------- >> ---- >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Bigdata-developers mailing list >> Big...@li... >> https://lists.sourceforge.net/lists/listinfo/bigdata-developers > |
|
From: Bryan T. <br...@sy...> - 2014-03-26 15:33:03
|
If you uncomment this line in web.xml then it will attempt to resolve the HALoadBalancerServlet and that would drag in the ProxyServlet. <servlet-class>com.bigdata.rdf.sail.webapp.HALoadBalancerServlet</servlet-c lass> Bryan On 3/26/14 8:30 AM, "Bryan Thompson" <br...@sy...> wrote: >There are several new jars for jetty 9. One of them includes this servlet >(jetty-proxy). Make sure that these are in place when using jetty. > >These jars should not be required for the tomcat war. Can you send the >full exception? I'd like to see where the exception is being thrown from. > >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-rewrite-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-proxy-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-webapp-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/servlet-api-3.1.0.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-xml-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-io-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-continuation-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-util-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-client-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-security-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-http-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-servlet-9.1.3.v20140225.jar >file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/j >e >tty/jetty-server-9.1.3.v20140225.jar > > > >Bryan > >On 3/26/14 8:26 AM, "Jim Balhoff" <ba...@ne...> wrote: > >>I am having trouble running the RDR branch bigdata.war in both tomcat and >>jetty. I get the error: >> >>java.lang.ClassNotFoundException: org.eclipse.jetty.proxy.ProxyServlet >> >>Is this something I need to add to my web app container? >> >>Thank you, >>Jim >> >>On Mar 12, 2014, at 6:52 AM, Bryan Thompson <br...@sy...> wrote: >> >>> I've fixed the builds in this branch. The problems all go back to the >>>changes to support configuration of jetty using jetty.xml and web.xml. >>> >>> I am still looking at eliminating the manual configuration of the NSS >>>and making code paths rely on web.xml, even for embedded use. I think >>>that is will work out and allowing override of the jetty.xml file >>>location will provide an option for complete customization. You will >>>also be able to override properties in jetty.xml using environment >>>variables and init parameters in web.xml using the NSS command line >>>options. >>> >>> Hopefully this will put an end to this aspect of the jetty refactoring. >>> >>> I have added a dependency on the jetty rewrite jar in preparation for >>>introducing load balancing into the HA cluster. It looks like we can do >>>this using the ProxyServlet in jetty. I will also be changing the >>>dependencies to jetty 9.1. >>> >>> Bryan >>> >>>------------------------------------------------------------------------ >>>- >>>----- >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>>their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/13534_NeoTech >>> _______________________________________________ >>> Bigdata-developers mailing list >>> Big...@li... >>> https://lists.sourceforge.net/lists/listinfo/bigdata-developers >> > > >-------------------------------------------------------------------------- >---- >Learn Graph Databases - Download FREE O'Reilly Book >"Graph Databases" is the definitive new guide to graph databases and their >applications. Written by three acclaimed leaders in the field, >this first edition is now available. Download your free book today! >http://p.sf.net/sfu/13534_NeoTech >_______________________________________________ >Bigdata-developers mailing list >Big...@li... >https://lists.sourceforge.net/lists/listinfo/bigdata-developers |
|
From: Bryan T. <br...@sy...> - 2014-03-26 15:31:27
|
There are several new jars for jetty 9. One of them includes this servlet (jetty-proxy). Make sure that these are in place when using jetty. These jars should not be required for the tomcat war. Can you send the full exception? I'd like to see where the exception is being thrown from. file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-rewrite-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-proxy-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-webapp-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/servlet-api-3.1.0.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-xml-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-io-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-continuation-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-util-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-client-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-security-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-http-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-servlet-9.1.3.v20140225.jar file://localhost/Users/bryan/Documents/workspace/RDR_NEW_SVN/bigdata/lib/je tty/jetty-server-9.1.3.v20140225.jar Bryan On 3/26/14 8:26 AM, "Jim Balhoff" <ba...@ne...> wrote: >I am having trouble running the RDR branch bigdata.war in both tomcat and >jetty. I get the error: > >java.lang.ClassNotFoundException: org.eclipse.jetty.proxy.ProxyServlet > >Is this something I need to add to my web app container? > >Thank you, >Jim > >On Mar 12, 2014, at 6:52 AM, Bryan Thompson <br...@sy...> wrote: > >> I've fixed the builds in this branch. The problems all go back to the >>changes to support configuration of jetty using jetty.xml and web.xml. >> >> I am still looking at eliminating the manual configuration of the NSS >>and making code paths rely on web.xml, even for embedded use. I think >>that is will work out and allowing override of the jetty.xml file >>location will provide an option for complete customization. You will >>also be able to override properties in jetty.xml using environment >>variables and init parameters in web.xml using the NSS command line >>options. >> >> Hopefully this will put an end to this aspect of the jetty refactoring. >> >> I have added a dependency on the jetty rewrite jar in preparation for >>introducing load balancing into the HA cluster. It looks like we can do >>this using the ProxyServlet in jetty. I will also be changing the >>dependencies to jetty 9.1. >> >> Bryan >> >>------------------------------------------------------------------------- >>----- >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >>their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Bigdata-developers mailing list >> Big...@li... >> https://lists.sourceforge.net/lists/listinfo/bigdata-developers > |
|
From: Jim B. <ba...@ne...> - 2014-03-26 15:26:38
|
I am having trouble running the RDR branch bigdata.war in both tomcat and jetty. I get the error: java.lang.ClassNotFoundException: org.eclipse.jetty.proxy.ProxyServlet Is this something I need to add to my web app container? Thank you, Jim On Mar 12, 2014, at 6:52 AM, Bryan Thompson <br...@sy...> wrote: > I've fixed the builds in this branch. The problems all go back to the changes to support configuration of jetty using jetty.xml and web.xml. > > I am still looking at eliminating the manual configuration of the NSS and making code paths rely on web.xml, even for embedded use. I think that is will work out and allowing override of the jetty.xml file location will provide an option for complete customization. You will also be able to override properties in jetty.xml using environment variables and init parameters in web.xml using the NSS command line options. > > Hopefully this will put an end to this aspect of the jetty refactoring. > > I have added a dependency on the jetty rewrite jar in preparation for introducing load balancing into the HA cluster. It looks like we can do this using the ProxyServlet in jetty. I will also be changing the dependencies to jetty 9.1. > > Bryan > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Bigdata-developers mailing list > Big...@li... > https://lists.sourceforge.net/lists/listinfo/bigdata-developers |
|
From: Bryan T. <br...@sy...> - 2014-03-22 20:39:43
|
Fyi. Bryan -------- Original message -------- From: Bryan Thompson Date:03/22/2014 4:28 PM (GMT-05:00) To: Bryan Thompson Subject: MPGraphv3 Release We are please to announce the v3 release of MPGraph. The MPGraph API makes it easy to develop high performance graph analytics on GPUs. The API is based on the Gather-Apply-Scatter (GAS) model as used in GraphLab. To deliver high performance computation and efficiently utilize the high memory bandwidth of GPUs, MPGraph’s CUDA kernels use multiple sophisticated strategies, such as vertex-degree-dependent dynamic parallelism granularity and frontier compaction. The v3 release includes a 5x – 10x performance gain in algorithms that have large frontiers (Connected Components, Page Rank, etc.). This performance gain is obtained by using a different strategy to load balance the GPU when the frontier is large. This strategy has more overhead for small frontiers, but outperforms the existing kernels when the frontier becomes large. MPGraph automatically chooses the best strategy for each iteration of the computation. Download MPGraph v3<http://sourceforge.net/projects/mpgraph/files/latest/download?source=files> from SourceForge now. Or you can get the latest development version from SVN: svn checkout svn://svn.code.sf.net/p/mpgraph/code/trunk You can learn more about MPGraph at GTC next week<http://registration.gputechconf.com/quicklink/b1cyGlI>. We will be presenting on Monday the 24th in San Jose. The goal of this session<http://registration.gputechconf.com/quicklink/fo9qLPo> is to demonstrate how our high level abstraction enables developers to quickly develop high performance graph analytics programs on GPUs with up to 3 billion edges traversed per second on a Tesla or Kepler GPU. High performance graph analytics are critical for a large range of application domains. The SIMT architecture of the GPUs and the irregularity nature of the graphs make it difficult to develop efficient graph analytics programs. In this session, we present an open source library that provides a high level abstraction for efficient graph analytics with minimal coding effort. We use several specific examples to show how to use our abstraction to implement efficient graph analytics in a matter of hours. We will be presenting new results for MPGraph v3<http://sourceforge.net/projects/mpgraph/>. These results include significant speedups for problems with very large frontiers. For more information about the GPU Technology Conference, see http://www.gputechconf.com/page/home.html. For more information about the MPGraph presentation, see http://registration.gputechconf.com/quicklink/b1cyGlI. For more information about MPGraph, see http://sourceforge.net/projects/mpgraph/ and http://www.systap.com/mpgraph/api/html/index.html. Thanks, Bryan Thompson |
|
From: Jeremy J C. <jj...@sy...> - 2014-03-12 18:30:40
|
We are moving our test server from one amazon instance to another and hitting JVM OOMEs Inspection of a heap dump shows huge amount of stuff (HashMapEntries and arrays of Bigdata values and statements) in the finalizer queue but not strongly reachable The tests are for our application, but they do hit bigdata: the actual test data size is small - and at the end of the day, we are more interested in tuning for large data sizes than small. The old test server is an m1.medium, 32 bit, java version "1.6.0_27" OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.10.04.2) OpenJDK Client VM (build 20.0-b12, mixed mode, sharing) whereas the new test server is 64 bit a c3 large java version "1.6.0_30" OpenJDK Runtime Environment (IcedTea6 1.13.1) (6b30-1.13.1-1ubuntu2~0.12.04.1) OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode) We have been running both with java -XX:+UseParallelOldGC -Xmx1G …. com.bigdata.rdf.sail.webapp.NanoSparqlServer I am thinking that we should be experimenting with either concurrent mark sweep, or the newer garbage first collector. We also should upgrade our JVM Does anyone have any thoughts or experience in this area? Jeremy J Carroll Principal Architect Syapse, Inc. |
|
From: Jeremy J C. <jj...@sy...> - 2014-03-12 18:22:03
|
FWIW: upgrading the JDK to Oracle's java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) fixed my problem Jeremy J Carroll Principal Architect Syapse, Inc. On Mar 12, 2014, at 10:30 AM, Jeremy J Carroll <jj...@sy...> wrote: > > We are moving our test server from one amazon instance to another and hitting JVM OOMEs > > Inspection of a heap dump shows huge amount of stuff (HashMapEntries and arrays of Bigdata values and statements) in the finalizer queue but not strongly reachable > > The tests are for our application, but they do hit bigdata: the actual test data size is small - and at the end of the day, we are more interested in tuning for large data sizes than small. > > The old test server is an m1.medium, 32 bit, > > java version "1.6.0_27" > OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.10.04.2) > OpenJDK Client VM (build 20.0-b12, mixed mode, sharing) > > > whereas the new test server is 64 bit a c3 large > > java version "1.6.0_30" > OpenJDK Runtime Environment (IcedTea6 1.13.1) (6b30-1.13.1-1ubuntu2~0.12.04.1) > OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode) > > > We have been running both with > > java -XX:+UseParallelOldGC -Xmx1G …. com.bigdata.rdf.sail.webapp.NanoSparqlServer > > I am thinking that we should be experimenting with either concurrent mark sweep, or the newer garbage first collector. > We also should upgrade our JVM > > Does anyone have any thoughts or experience in this area? > > > Jeremy J Carroll > Principal Architect > Syapse, Inc. > > > |
|
From: Bryan T. <br...@sy...> - 2014-03-12 11:52:17
|
I've fixed the builds in this branch. The problems all go back to the changes to support configuration of jetty using jetty.xml and web.xml. I am still looking at eliminating the manual configuration of the NSS and making code paths rely on web.xml, even for embedded use. I think that is will work out and allowing override of the jetty.xml file location will provide an option for complete customization. You will also be able to override properties in jetty.xml using environment variables and init parameters in web.xml using the NSS command line options. Hopefully this will put an end to this aspect of the jetty refactoring. I have added a dependency on the jetty rewrite jar in preparation for introducing load balancing into the HA cluster. It looks like we can do this using the ProxyServlet in jetty. I will also be changing the dependencies to jetty 9.1. Bryan |
|
From: Bryan T. <br...@sy...> - 2014-03-07 13:48:38
|
I managed to get a bit into the problem before we lost power here. The root cause is that the context path for the NSS has changed from an implicit default of "/" to "/bigdata" for the embedded and HA deployment models. This is the same context path that is used by the WAR. This standardization of the context path is a big improvement, but the unit tests are breaking due to assumptions that the context path is "/". I am pretty sure that the problem is mostly (and maybe entirely) due to the test suite assumptions. However, it would be advisable to not roll forward on the RDR branch until power is restored and I get a chance to commit this bug fix. I'll try to work the issue while on batter power and a cell, but obviously I have only limited power from those sources.
Thanks,
Bryan
From: Bryan Thompson <br...@sy...<mailto:br...@sy...>>
Date: Thursday, March 6, 2014 9:17 PM
To: "Big...@li...<mailto:Big...@li...>" <Big...@li...<mailto:Big...@li...>>
Subject: [Bigdata-developers] Fwd: [Bigdata] #730: Allow configuration of embedded NSS jetty server using jetty-web.xml
I appear to have broken the RDR branch. I'll fix this in the am. It is reporting OOMs out of CI.
Bryan
Begin forwarded message:
From: TRAC Bigdata <no...@sy...<mailto:no...@sy...>>
Date: March 6, 2014 at 5:39:11 PM EST
Subject: Re: [Bigdata] #730: Allow configuration of embedded NSS jetty server using jetty-web.xml
#730: Allow configuration of embedded NSS jetty server using jetty-web.xml
-------------------------------+-----------------------------------
Reporter: bryanthompson | Owner: bryanthompson
Type: enhancement | Status: closed
Priority: major | Milestone: High Availability
Component: NanoSparqlServer | Version: BIGDATA_RELEASE_1_2_2
Resolution: fixed | Keywords:
-------------------------------+-----------------------------------
Comment (by bryanthompson):
Checkpoint in the RDR branch on a continued refactoring to support both
the web.xml and jetty.xml based configuration of the HAJournalServer, the
restructuring of the webapp, and forward movement to jetty 9.1. jetty 9.1
will give us the ability to transparently map http://localhost:8080 onto
http://localhost:8080/bigdata (which we can probably accomplish anyway
with jetty-rewrite). It will also provide us with a supportable basis for
the ProxyServlet to support transparent load balancing. Finally, jetty 9.1
has a new IO layer and could potentially increase http performance - it is
certainly the starting point for optimization at that layer.
See #730 (Allow configuration of embedded NSS jetty server using jetty-
web.xml)
See #624 (Transparent proxy of requests for HA)
Committed revision r7916.
--
Ticket URL: <http://trac.bigdata.com/ticket/730#comment:11>
Bigdata <trac.bigdata.com<http://trac.bigdata.com>>
Bigdata Triple Store
|
|
From: Bryan T. <br...@sy...> - 2014-03-07 02:18:39
|
I appear to have broken the RDR branch. I'll fix this in the am. It is reporting OOMs out of CI.
Bryan
Begin forwarded message:
From: TRAC Bigdata <no...@sy...<mailto:no...@sy...>>
Date: March 6, 2014 at 5:39:11 PM EST
Subject: Re: [Bigdata] #730: Allow configuration of embedded NSS jetty server using jetty-web.xml
#730: Allow configuration of embedded NSS jetty server using jetty-web.xml
-------------------------------+-----------------------------------
Reporter: bryanthompson | Owner: bryanthompson
Type: enhancement | Status: closed
Priority: major | Milestone: High Availability
Component: NanoSparqlServer | Version: BIGDATA_RELEASE_1_2_2
Resolution: fixed | Keywords:
-------------------------------+-----------------------------------
Comment (by bryanthompson):
Checkpoint in the RDR branch on a continued refactoring to support both
the web.xml and jetty.xml based configuration of the HAJournalServer, the
restructuring of the webapp, and forward movement to jetty 9.1. jetty 9.1
will give us the ability to transparently map http://localhost:8080 onto
http://localhost:8080/bigdata (which we can probably accomplish anyway
with jetty-rewrite). It will also provide us with a supportable basis for
the ProxyServlet to support transparent load balancing. Finally, jetty 9.1
has a new IO layer and could potentially increase http performance - it is
certainly the starting point for optimization at that layer.
See #730 (Allow configuration of embedded NSS jetty server using jetty-
web.xml)
See #624 (Transparent proxy of requests for HA)
Committed revision r7916.
--
Ticket URL: <http://trac.bigdata.com/ticket/730#comment:11>
Bigdata <trac.bigdata.com<http://trac.bigdata.com>>
Bigdata Triple Store
|
|
From: Bryan T. <br...@sy...> - 2014-03-04 22:03:51
|
We should do these merges to catch up the side-branches in the next few days. There have been changes in build.xml, the web app layout, and some (small) changes in the HA test suite setup. There have also been changes to the HAJournalServer, NanoSparqlServer, and some related files. This was to support configuration using jetty.xml and web.xml for the HAJournalServer (ticket #730). We need to do these merges to avoid having increased divergence. Bryan |
|
From: Bryan T. <br...@sy...> - 2014-03-04 21:50:28
|
FYI, this works for me to relocate from the old SVN URL to the new one. svn switch --relocate https://bigdata.svn.sourceforge.net/svnroot/bigdata/branches/BIGDATA_RELEASE_1_3_0 https://svn.code.sf.net/p/bigdata/code/branches/BIGDATA_RELEASE_1_3_0 |
|
From: Bryan T. <br...@sy...> - 2014-03-03 22:15:18
|
I think that I have this pretty much worked out with the web app restructuring. I am now running test suites to ensure that things work – yep, all is good for the NSS test suite and the basic SPARQL test suites. I still need to fix up the HA CI test suites. Since the NSS port is no longer part of the HAJournal.config file, it needs to get pass into the child process's environment. This is at least partly working by copying the entire bigdata-war/src directory structure each time we launch an HAJournalServer under test suite control. I will look for easier answers. You do need to use some different properties to run the HAJournalServer processes under the IDE for test/debug purposes: java -Djava.security.policy=policy.all -Djava.util.logging.config.file=bigdata/src/resources/logging/logging.properties -Dlog4j.configuration=bigdata/src/resources/logging/log4j-dev.properties -Djetty.port=8090 com.bigdata.journal.jini.ha.HAJournalServer bigdata-jini/src/java/com/bigdata/journal/jini/ha/HAJournal-A.config Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 1:09 PM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. That ticket will not interfere with what I am doing. I do need to make some servlet changes as well, but let me work through the jetty web app structure first and then bring that change into the RDR branch. We can coordinate separately about the JSP page changes. In addition to the load balancer, I have #753<http://trac.bigdata.com/ticket/753> HA doLocalAbort() should interrupt NSS requests and AbstractTasks<http://trac.bigdata.com/ticket/753> #566<http://trac.bigdata.com/ticket/566> Concurrent unisolated operations against multiple KBs on the same Journal<http://trac.bigdata.com/ticket/566> The schedule is not yet set on those tickets. Thanks, Bryan From: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Date: Monday, March 3, 2014 1:00 PM To: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Hi Bryan, >From my perspective, it is very simple to update references to static files and their locations, so if you are happy working out locations, I can update my side of things quickly and easily whenever you are ready. I am not very au fait with Jetty configuration and best practices, or indeed the various ways bigdata is deployed, so it might be best left in your hands. If you have any queries though, or would like me to look into something, let me know! The only way I am running things just now is by running NanoSparqlServer in Eclipse with the port and properties file as arguments. So far, my commits have all been client-side code, so I don't have any NSS test cases that need to be updated. (Planning on using Selenium for workbench testing, but it's not in place yet.) The only server-side change I'm intending to make just now is [1]. I can hold off on this for now if it'd be less hassle to wait until we have things tidied up. Toby [1] http://trac.bigdata.com/ticket/834 On 3 March 2014 08:34, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote: I am also curious where we should locate the jetty.xml file, especially if we have multiple web apps at some point. Right now, I am looking at locating it in: bigdata-war/src/WEB-INF But maybe this would be better off under src/resources/config/jetty.xml We could then stage it into the right location. The staged files could then be edited before creating a distribution that was specific to a given organization's operational requirements. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:21 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Here is a checklist for this refactoring. I am trying to capture the different ways in which we start the NSS and make sure that they all continue to function correctly. Let me know if you have any other NSS use cases / tests. - NSS test suite. - NSS starts and index.html is available under IDE. - NSS starts under ant scripts for lubm, bsbm, govtrack, etc. - Embedded NSS sample code works. - HAJournalServer ServiceStarter deployment works, index.html is available, etc. - nanoSparqlServer.sh script works for index.html for scale-out. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:17 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Toby, I need to restructure the bigdata-war to have the same structure as a web app. You are currently putting files into bigdata-war/html because they are not resolvable from the bigdata-war/images directory. This is because the directory layout is wrong in SVN. This is also the root problem for controlling the deployment using jetty.xml. I also think that we should organize this to provide for multiple web applications. That might make it easier to accelerate development on the UX, handle load balancing through proxying, etc. These changes will break some of the ways in which the code and ant scripts currently start the NSS and access the files within it. I am going to chase down some of those dependencies, but I want to talk through what the target file system structure should look like. Right now, SVN looks like: bigdata-war/src/html (index.html, etc.) . bigdata-war/src/jsp (empty) bigdata-war/src/images (empty) bigdata-war/src/resources (should disappear) bigdata-war/src/resources/WEB-INF (should become bigdata-war/src/WEB-INF) bigdata-war/src/resources/log4j.properties (should become bigdata-war/src/log4j.properties) bigdata-war/src/resources/RWStore.properties (should become bigdata-war/src/RWStore.properties) We currently push the bigdata-war part of the code into (a) the bigdata.jar (to support embedded deployment of the NSS); (b) the bigdata.war, which bundles the bigdata.jar but also has the files in the WAR in their target locations for the deployed web app. This is of course to support the Servlet Container based deployment. And then we access the files from Eclipse when doing testing, which is a different embedded context. CI, the HAJournalServer deployment, and the scale-out deployment would appear to access these files within the bigdata.jar. For the HAJournalServer's ServiceStarter deployment (based on "ant stage") we should definitely put the web app files into the file system and then wrap them into a tar ball for deployment. I am trying to figure out whether I should make these changes in the main 1.3.x development branch, and then bring them into the RDR branch where you are working or do this the other way around. The problem is that some of this needs to be in the main development branch for the load balancer and jetty configuration tickets [1,2,3]. I think that the main problem is going to be how the code resolves the RWStore.properties and WEB-INF directories. This is probably pretty localized inside of the NanoSparqlServer class. Thanks, Bryan [1] #730<http://trac.bigdata.com/ticket/730> Allow configuration of embedded NSS jetty server using jetty-web.xml<http://trac.bigdata.com/ticket/730> [2] #624<http://trac.bigdata.com/ticket/624> Transparent proxy of requests for HA<http://trac.bigdata.com/ticket/624> [3] There is also one more ticket that I need to file for a simpler form of the load balancer (using redirection and rewrites of the internal and external URIs). |
|
From: Bryan T. <br...@sy...> - 2014-03-03 18:10:41
|
That ticket will not interfere with what I am doing. I do need to make some servlet changes as well, but let me work through the jetty web app structure first and then bring that change into the RDR branch. We can coordinate separately about the JSP page changes. In addition to the load balancer, I have #753<http://trac.bigdata.com/ticket/753> HA doLocalAbort() should interrupt NSS requests and AbstractTasks<http://trac.bigdata.com/ticket/753> #566<http://trac.bigdata.com/ticket/566> Concurrent unisolated operations against multiple KBs on the same Journal<http://trac.bigdata.com/ticket/566> The schedule is not yet set on those tickets. Thanks, Bryan From: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Date: Monday, March 3, 2014 1:00 PM To: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Hi Bryan, >From my perspective, it is very simple to update references to static files and their locations, so if you are happy working out locations, I can update my side of things quickly and easily whenever you are ready. I am not very au fait with Jetty configuration and best practices, or indeed the various ways bigdata is deployed, so it might be best left in your hands. If you have any queries though, or would like me to look into something, let me know! The only way I am running things just now is by running NanoSparqlServer in Eclipse with the port and properties file as arguments. So far, my commits have all been client-side code, so I don't have any NSS test cases that need to be updated. (Planning on using Selenium for workbench testing, but it's not in place yet.) The only server-side change I'm intending to make just now is [1]. I can hold off on this for now if it'd be less hassle to wait until we have things tidied up. Toby [1] http://trac.bigdata.com/ticket/834 On 3 March 2014 08:34, Bryan Thompson <br...@sy...<mailto:br...@sy...>> wrote: I am also curious where we should locate the jetty.xml file, especially if we have multiple web apps at some point. Right now, I am looking at locating it in: bigdata-war/src/WEB-INF But maybe this would be better off under src/resources/config/jetty.xml We could then stage it into the right location. The staged files could then be edited before creating a distribution that was specific to a given organization's operational requirements. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:21 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Here is a checklist for this refactoring. I am trying to capture the different ways in which we start the NSS and make sure that they all continue to function correctly. Let me know if you have any other NSS use cases / tests. - NSS test suite. - NSS starts and index.html is available under IDE. - NSS starts under ant scripts for lubm, bsbm, govtrack, etc. - Embedded NSS sample code works. - HAJournalServer ServiceStarter deployment works, index.html is available, etc. - nanoSparqlServer.sh script works for index.html for scale-out. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:17 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Toby, I need to restructure the bigdata-war to have the same structure as a web app. You are currently putting files into bigdata-war/html because they are not resolvable from the bigdata-war/images directory. This is because the directory layout is wrong in SVN. This is also the root problem for controlling the deployment using jetty.xml. I also think that we should organize this to provide for multiple web applications. That might make it easier to accelerate development on the UX, handle load balancing through proxying, etc. These changes will break some of the ways in which the code and ant scripts currently start the NSS and access the files within it. I am going to chase down some of those dependencies, but I want to talk through what the target file system structure should look like. Right now, SVN looks like: bigdata-war/src/html (index.html, etc.) . bigdata-war/src/jsp (empty) bigdata-war/src/images (empty) bigdata-war/src/resources (should disappear) bigdata-war/src/resources/WEB-INF (should become bigdata-war/src/WEB-INF) bigdata-war/src/resources/log4j.properties (should become bigdata-war/src/log4j.properties) bigdata-war/src/resources/RWStore.properties (should become bigdata-war/src/RWStore.properties) We currently push the bigdata-war part of the code into (a) the bigdata.jar (to support embedded deployment of the NSS); (b) the bigdata.war, which bundles the bigdata.jar but also has the files in the WAR in their target locations for the deployed web app. This is of course to support the Servlet Container based deployment. And then we access the files from Eclipse when doing testing, which is a different embedded context. CI, the HAJournalServer deployment, and the scale-out deployment would appear to access these files within the bigdata.jar. For the HAJournalServer's ServiceStarter deployment (based on "ant stage") we should definitely put the web app files into the file system and then wrap them into a tar ball for deployment. I am trying to figure out whether I should make these changes in the main 1.3.x development branch, and then bring them into the RDR branch where you are working or do this the other way around. The problem is that some of this needs to be in the main development branch for the load balancer and jetty configuration tickets [1,2,3]. I think that the main problem is going to be how the code resolves the RWStore.properties and WEB-INF directories. This is probably pretty localized inside of the NanoSparqlServer class. Thanks, Bryan [1] #730<http://trac.bigdata.com/ticket/730> Allow configuration of embedded NSS jetty server using jetty-web.xml<http://trac.bigdata.com/ticket/730> [2] #624<http://trac.bigdata.com/ticket/624> Transparent proxy of requests for HA<http://trac.bigdata.com/ticket/624> [3] There is also one more ticket that I need to file for a simpler form of the load balancer (using redirection and rewrites of the internal and external URIs). |
|
From: Toby C. <tob...@gm...> - 2014-03-03 18:00:33
|
Hi Bryan, >From my perspective, it is very simple to update references to static files and their locations, so if you are happy working out locations, I can update my side of things quickly and easily whenever you are ready. I am not very au fait with Jetty configuration and best practices, or indeed the various ways bigdata is deployed, so it might be best left in your hands. If you have any queries though, or would like me to look into something, let me know! The only way I am running things just now is by running NanoSparqlServer in Eclipse with the port and properties file as arguments. So far, my commits have all been client-side code, so I don't have any NSS test cases that need to be updated. (Planning on using Selenium for workbench testing, but it's not in place yet.) The only server-side change I'm intending to make just now is [1]. I can hold off on this for now if it'd be less hassle to wait until we have things tidied up. Toby [1] http://trac.bigdata.com/ticket/834 On 3 March 2014 08:34, Bryan Thompson <br...@sy...> wrote: > I am also curious where we should locate the jetty.xml file, especially if > we have multiple web apps at some point. Right now, I am looking at > locating it in: > > bigdata-war/src/WEB-INF > > But maybe this would be better off under > > src/resources/config/jetty.xml > > We could then stage it into the right location. The staged files could > then be edited before creating a distribution that was specific to a given > organization's operational requirements. > > Bryan > > From: Bryan Thompson <br...@sy...> > Date: Monday, March 3, 2014 11:21 AM > > To: Toby Craig <tob...@gm...> > Cc: "big...@li..." < > big...@li...> > Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war > section of SVN. > > Here is a checklist for this refactoring. I am trying to capture the > different ways in which we start the NSS and make sure that they all > continue to function correctly. Let me know if you have any other NSS use > cases / tests. > > - NSS test suite. > - NSS starts and index.html is available under IDE. > - NSS starts under ant scripts for lubm, bsbm, govtrack, etc. > - Embedded NSS sample code works. > - HAJournalServer ServiceStarter deployment works, index.html is > available, etc. > - nanoSparqlServer.sh script works for index.html for scale-out. > > Bryan > > From: Bryan Thompson <br...@sy...> > Date: Monday, March 3, 2014 11:17 AM > To: Toby Craig <tob...@gm...> > Cc: "big...@li..." < > big...@li...> > Subject: [Bigdata-developers] Restructuring of the bigdata-war section of > SVN. > > Toby, > > I need to restructure the bigdata-war to have the same structure as a web > app. You are currently putting files into bigdata-war/html because they are > not resolvable from the bigdata-war/images directory. This is because the > directory layout is wrong in SVN. This is also the root problem for > controlling the deployment using jetty.xml. I also think that we should > organize this to provide for multiple web applications. That might make it > easier to accelerate development on the UX, handle load balancing through > proxying, etc. These changes will break some of the ways in which the code > and ant scripts currently start the NSS and access the files within it. I > am going to chase down some of those dependencies, but I want to talk > through what the target file system structure should look like. > > Right now, SVN looks like: > > bigdata-war/src/html (index.html, etc.) . > bigdata-war/src/jsp (empty) > bigdata-war/src/images (empty) > bigdata-war/src/resources (should disappear) > bigdata-war/src/resources/WEB-INF (should become bigdata-war/src/WEB-INF) > bigdata-war/src/resources/log4j.properties (should become > bigdata-war/src/log4j.properties) > bigdata-war/src/resources/RWStore.properties (should become > bigdata-war/src/RWStore.properties) > > We currently push the bigdata-war part of the code into (a) the > bigdata.jar (to support embedded deployment of the NSS); (b) the > bigdata.war, which bundles the bigdata.jar but also has the files in the > WAR in their target locations for the deployed web app. This is of course > to support the Servlet Container based deployment. And then we access the > files from Eclipse when doing testing, which is a different embedded > context. CI, the HAJournalServer deployment, and the scale-out deployment > would appear to access these files within the bigdata.jar. For the > HAJournalServer's ServiceStarter deployment (based on "ant stage") we > should definitely put the web app files into the file system and then wrap > them into a tar ball for deployment. > > I am trying to figure out whether I should make these changes in the main > 1.3.x development branch, and then bring them into the RDR branch where you > are working or do this the other way around. The problem is that some of > this needs to be in the main development branch for the load balancer and > jetty configuration tickets [1,2,3]. I think that the main problem is > going to be how the code resolves the RWStore.properties and WEB-INF > directories. This is probably pretty localized inside of the > NanoSparqlServer class. > > Thanks, > Bryan > > [1] #730 <http://trac.bigdata.com/ticket/730>Allow configuration of > embedded NSS jetty server using jetty-web.xml<http://trac.bigdata.com/ticket/730> > [2] #624 <http://trac.bigdata.com/ticket/624>Transparent proxy of > requests for HA <http://trac.bigdata.com/ticket/624> > [3] There is also one more ticket that I need to file for a simpler form > of the load balancer (using redirection and rewrites of the internal and > external URIs). > |
|
From: Bryan T. <br...@sy...> - 2014-03-03 16:34:26
|
I am also curious where we should locate the jetty.xml file, especially if we have multiple web apps at some point. Right now, I am looking at locating it in: bigdata-war/src/WEB-INF But maybe this would be better off under src/resources/config/jetty.xml We could then stage it into the right location. The staged files could then be edited before creating a distribution that was specific to a given organization's operational requirements. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:21 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Here is a checklist for this refactoring. I am trying to capture the different ways in which we start the NSS and make sure that they all continue to function correctly. Let me know if you have any other NSS use cases / tests. - NSS test suite. - NSS starts and index.html is available under IDE. - NSS starts under ant scripts for lubm, bsbm, govtrack, etc. - Embedded NSS sample code works. - HAJournalServer ServiceStarter deployment works, index.html is available, etc. - nanoSparqlServer.sh script works for index.html for scale-out. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:17 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Toby, I need to restructure the bigdata-war to have the same structure as a web app. You are currently putting files into bigdata-war/html because they are not resolvable from the bigdata-war/images directory. This is because the directory layout is wrong in SVN. This is also the root problem for controlling the deployment using jetty.xml. I also think that we should organize this to provide for multiple web applications. That might make it easier to accelerate development on the UX, handle load balancing through proxying, etc. These changes will break some of the ways in which the code and ant scripts currently start the NSS and access the files within it. I am going to chase down some of those dependencies, but I want to talk through what the target file system structure should look like. Right now, SVN looks like: bigdata-war/src/html (index.html, etc.) . bigdata-war/src/jsp (empty) bigdata-war/src/images (empty) bigdata-war/src/resources (should disappear) bigdata-war/src/resources/WEB-INF (should become bigdata-war/src/WEB-INF) bigdata-war/src/resources/log4j.properties (should become bigdata-war/src/log4j.properties) bigdata-war/src/resources/RWStore.properties (should become bigdata-war/src/RWStore.properties) We currently push the bigdata-war part of the code into (a) the bigdata.jar (to support embedded deployment of the NSS); (b) the bigdata.war, which bundles the bigdata.jar but also has the files in the WAR in their target locations for the deployed web app. This is of course to support the Servlet Container based deployment. And then we access the files from Eclipse when doing testing, which is a different embedded context. CI, the HAJournalServer deployment, and the scale-out deployment would appear to access these files within the bigdata.jar. For the HAJournalServer's ServiceStarter deployment (based on "ant stage") we should definitely put the web app files into the file system and then wrap them into a tar ball for deployment. I am trying to figure out whether I should make these changes in the main 1.3.x development branch, and then bring them into the RDR branch where you are working or do this the other way around. The problem is that some of this needs to be in the main development branch for the load balancer and jetty configuration tickets [1,2,3]. I think that the main problem is going to be how the code resolves the RWStore.properties and WEB-INF directories. This is probably pretty localized inside of the NanoSparqlServer class. Thanks, Bryan [1] #730<http://trac.bigdata.com/ticket/730> Allow configuration of embedded NSS jetty server using jetty-web.xml<http://trac.bigdata.com/ticket/730> [2] #624<http://trac.bigdata.com/ticket/624> Transparent proxy of requests for HA<http://trac.bigdata.com/ticket/624> [3] There is also one more ticket that I need to file for a simpler form of the load balancer (using redirection and rewrites of the internal and external URIs). |
|
From: Bryan T. <br...@sy...> - 2014-03-03 16:22:00
|
Here is a checklist for this refactoring. I am trying to capture the different ways in which we start the NSS and make sure that they all continue to function correctly. Let me know if you have any other NSS use cases / tests. - NSS test suite. - NSS starts and index.html is available under IDE. - NSS starts under ant scripts for lubm, bsbm, govtrack, etc. - Embedded NSS sample code works. - HAJournalServer ServiceStarter deployment works, index.html is available, etc. - nanoSparqlServer.sh script works for index.html for scale-out. Bryan From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Monday, March 3, 2014 11:17 AM To: Toby Craig <tob...@gm...<mailto:tob...@gm...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: [Bigdata-developers] Restructuring of the bigdata-war section of SVN. Toby, I need to restructure the bigdata-war to have the same structure as a web app. You are currently putting files into bigdata-war/html because they are not resolvable from the bigdata-war/images directory. This is because the directory layout is wrong in SVN. This is also the root problem for controlling the deployment using jetty.xml. I also think that we should organize this to provide for multiple web applications. That might make it easier to accelerate development on the UX, handle load balancing through proxying, etc. These changes will break some of the ways in which the code and ant scripts currently start the NSS and access the files within it. I am going to chase down some of those dependencies, but I want to talk through what the target file system structure should look like. Right now, SVN looks like: bigdata-war/src/html (index.html, etc.) . bigdata-war/src/jsp (empty) bigdata-war/src/images (empty) bigdata-war/src/resources (should disappear) bigdata-war/src/resources/WEB-INF (should become bigdata-war/src/WEB-INF) bigdata-war/src/resources/log4j.properties (should become bigdata-war/src/log4j.properties) bigdata-war/src/resources/RWStore.properties (should become bigdata-war/src/RWStore.properties) We currently push the bigdata-war part of the code into (a) the bigdata.jar (to support embedded deployment of the NSS); (b) the bigdata.war, which bundles the bigdata.jar but also has the files in the WAR in their target locations for the deployed web app. This is of course to support the Servlet Container based deployment. And then we access the files from Eclipse when doing testing, which is a different embedded context. CI, the HAJournalServer deployment, and the scale-out deployment would appear to access these files within the bigdata.jar. For the HAJournalServer's ServiceStarter deployment (based on "ant stage") we should definitely put the web app files into the file system and then wrap them into a tar ball for deployment. I am trying to figure out whether I should make these changes in the main 1.3.x development branch, and then bring them into the RDR branch where you are working or do this the other way around. The problem is that some of this needs to be in the main development branch for the load balancer and jetty configuration tickets [1,2,3]. I think that the main problem is going to be how the code resolves the RWStore.properties and WEB-INF directories. This is probably pretty localized inside of the NanoSparqlServer class. Thanks, Bryan [1] #730<http://trac.bigdata.com/ticket/730> Allow configuration of embedded NSS jetty server using jetty-web.xml<http://trac.bigdata.com/ticket/730> [2] #624<http://trac.bigdata.com/ticket/624> Transparent proxy of requests for HA<http://trac.bigdata.com/ticket/624> [3] There is also one more ticket that I need to file for a simpler form of the load balancer (using redirection and rewrites of the internal and external URIs). |
|
From: Bryan T. <br...@sy...> - 2014-03-03 16:19:05
|
Toby, I need to restructure the bigdata-war to have the same structure as a web app. You are currently putting files into bigdata-war/html because they are not resolvable from the bigdata-war/images directory. This is because the directory layout is wrong in SVN. This is also the root problem for controlling the deployment using jetty.xml. I also think that we should organize this to provide for multiple web applications. That might make it easier to accelerate development on the UX, handle load balancing through proxying, etc. These changes will break some of the ways in which the code and ant scripts currently start the NSS and access the files within it. I am going to chase down some of those dependencies, but I want to talk through what the target file system structure should look like. Right now, SVN looks like: bigdata-war/src/html (index.html, etc.) . bigdata-war/src/jsp (empty) bigdata-war/src/images (empty) bigdata-war/src/resources (should disappear) bigdata-war/src/resources/WEB-INF (should become bigdata-war/src/WEB-INF) bigdata-war/src/resources/log4j.properties (should become bigdata-war/src/log4j.properties) bigdata-war/src/resources/RWStore.properties (should become bigdata-war/src/RWStore.properties) We currently push the bigdata-war part of the code into (a) the bigdata.jar (to support embedded deployment of the NSS); (b) the bigdata.war, which bundles the bigdata.jar but also has the files in the WAR in their target locations for the deployed web app. This is of course to support the Servlet Container based deployment. And then we access the files from Eclipse when doing testing, which is a different embedded context. CI, the HAJournalServer deployment, and the scale-out deployment would appear to access these files within the bigdata.jar. For the HAJournalServer's ServiceStarter deployment (based on "ant stage") we should definitely put the web app files into the file system and then wrap them into a tar ball for deployment. I am trying to figure out whether I should make these changes in the main 1.3.x development branch, and then bring them into the RDR branch where you are working or do this the other way around. The problem is that some of this needs to be in the main development branch for the load balancer and jetty configuration tickets [1,2,3]. I think that the main problem is going to be how the code resolves the RWStore.properties and WEB-INF directories. This is probably pretty localized inside of the NanoSparqlServer class. Thanks, Bryan [1] #730<http://trac.bigdata.com/ticket/730> Allow configuration of embedded NSS jetty server using jetty-web.xml<http://trac.bigdata.com/ticket/730> [2] #624<http://trac.bigdata.com/ticket/624> Transparent proxy of requests for HA<http://trac.bigdata.com/ticket/624> [3] There is also one more ticket that I need to file for a simpler form of the load balancer (using redirection and rewrites of the internal and external URIs). |
|
From: Martyn C. <ma...@sy...> - 2014-02-20 08:17:17
|
In order to merge the trac user names I need to know what user name is display when you log in with your openID. Typically it will be <Firstname Lastname> with a space between. But some people may include a middle initial, so I need to know the precise name to do the merge. For the wiki the new user identities are directly accessible with SQL access, so I can tie these up more simply. - Martyn On 19/02/2014 19:51, Bryan Thompson wrote: > Martyn has to do a migration for your username. What you do is login > with Google's OpenID. Martyn has scripts to port your OpenID login > into the wiki and trac systems. I do not know if he has already run > those scripts for you, or if you need to login before he can run the > script. I think that it might be the latter, in which case you will > need to let him know that you have logged in and then he can do the > magic script dance for you. > Bryan > > From: Mike Personick <mi...@sy... <mailto:mi...@sy...>> > Date: Wednesday, February 19, 2014 2:49 PM > To: Bryan Thompson <br...@sy... <mailto:br...@sy...>>, > Martyn Cutcher <ma...@sy... <mailto:ma...@sy...>>, > "big...@li... > <mailto:big...@li...>" > <big...@li... > <mailto:big...@li...>> > Subject: Re: [Bigdata-developers] Bigdata Allura Migration > > I'm not exactly sure I understand how to log in to the new trac such > that I still have access to my old tickets under my sourceforge user name. > > > > From: Bryan Thompson <br...@sy... <mailto:br...@sy...>> > Date: Wednesday, February 19, 2014 5:51 AM > To: Martyn Cutcher <ma...@sy... <mailto:ma...@sy...>>, > "big...@li... > <mailto:big...@li...>" > <big...@li... > <mailto:big...@li...>> > Subject: Re: [Bigdata-developers] Bigdata Allura Migration > > We have done the basic project migration. Developers probably need to > check out a CLEAN COPY of bigdata from the new SVN repository (see > https://sourceforge.net/projects/bigdata/). If you have any > uncommitted edits, then will need to be applied to that clean checkout > before they can be committed to the new SVN repository location! > > Thanks, > Bryanb > > From: Martyn Cutcher <ma...@sy... <mailto:ma...@sy...>> > Date: Tuesday, February 18, 2014 10:50 AM > To: "big...@li... > <mailto:big...@li...>" > <big...@li... > <mailto:big...@li...>> > Subject: [Bigdata-developers] Bigdata Allura Migration > > Hi all, > > Very soon we will be migrating the Bigdata sourceforge account to the > new Allura platform. > > We have taken the decision to continue to use the existing Trac issue > management system and MediaWiki, but will now host these applications > ourselves. We have set up the applications using a server on Amazon EC2. > > One thing that will change is the user management previously > integrated with sourceforge. Instead we have configured the new > applications to use OpenID. Users will login using their Google account. > > This leads to a few issues for existing users, since in some cases we > need to be able to identify the new OpenID users with their original > accounts. > > The URLs to access the applications are: > > http://trac.bigdata.com > http://wiki.bigdata.com > > Most users can simply login to both using an OpenID account - we have > restricted the trac login to a required Google account and are aware > of the inconsistency of login options between the wiki and trac, but > please bear with us while we try and iron out the wrinkles. > > If you have previously created or commented on trac tickets, or edited > wiki articles then we will need to run some scripts to tie your new > OpenID user to the existing trac or wiki user. > > If so then please email me at ma...@sy... with your old and new > user names for trac and/or wiki as appropriate and I will try to get > your configuration updated ASAP. > > Your patience will be greatly appreciated! > > cheers > > - Martyn > > _Preliminary Schedule__- Wednesday 19th February_ > > Trac and Wiki > > 1) 0800 GMT > > Freeze new Ticket creation and updates on Trac > Freeze updates to Wiki > > Migrate Trac and Wiki data > > 2) 1200 GMT Trac and Wiki will be available from new locations for > read access > > 3) Developers should login to trac.bigdata.com and wiki.bigdata.com > and mail me their user names for joining. > > Allura SVN > > A) 1200 GMT Freeze any updates to SVN. Commit local changes to > developer sub-branches where possible. > > B) 1400 GMT commence migration of SVN to Allura > > C) Notification of new SVN URLs will be emailed when ready > > |
|
From: Bryan T. <br...@sy...> - 2014-02-19 20:38:19
|
I just tried this and was able to commit: I checked out using this SVN URL: https://svn.code.sf.net/p/bigdata/code/branches/BIGDATA_RELEASE_1_3_0 Checked out revision 7850. commit -m "updated the URLs to point at the new wiki location" /Users/bryan/Documents/workspace/BIGDATA_RELEASE_1_3_0_NEW_SVN/bigdata-war/src/html/index.html Sending /Users/bryan/Documents/workspace/BIGDATA_RELEASE_1_3_0_NEW_SVN/bigdata-war/src/html/index.html Transmitting file data ... Committed revision 7851. A /Users/bryan/Documents/workspace/BIGDATA_RELEASE_1_3_0_NEW_SVN/bigdata-commons/src/test/com Bryan From: Mike Personick <mi...@sy...<mailto:mi...@sy...>> Date: Wednesday, February 19, 2014 3:32 PM To: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Cc: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] FW: SourceForge Project Upgrade - Code Repo Complete * SVN:https://svn.code.sf.net/p/bigdata/code/(read/write) On Feb 19, 2014, at 1:32 PM, "Bryan Thompson" <br...@sy...<mailto:br...@sy...>> wrote: Which URL did you use to checkout from svn? On Feb 19, 2014, at 3:00 PM, "Mike Personick" <mi...@sy...<mailto:mi...@sy...>> wrote: Yes, I read the notice carefully, and I did a fresh checkout from the new URL. I cannot commit against that fresh checkout. On 2/19/14 12:55 PM, "Bryan Thompson" <br...@sy...<mailto:br...@sy...>> wrote: You need to do a new checkout from the new SVN. Did you do that? Then you have to migrate any changes. That is why Martyn sent out notice before the change overŠ. Bryan On 2/19/14 2:50 PM, "Mike Personick" <mi...@sy...<mailto:mi...@sy...>> wrote: I cannot commit using my sourceforge credentials. On 2/19/14 6:50 AM, "Bryan Thompson" <br...@sy...<mailto:br...@sy...>> wrote: FYI, the new SVN repository should be ready for use. Thanks, Bryan On 2/19/14 8:15 AM, "SourceForge.net<http://SourceForge.net>" <nor...@in...<mailto:nor...@in...>> wrote: Your code repository in upgraded project bigdata is now ready for use. Old repository url: http://bigdata.svn.sourceforge.net/svnroot/bigdata New repository checkout command: svn checkout --username=thompsonbry svn+ssh://tho...@sv.../p/bigdata/code/ bigdata-code You should do a checkout using the new repository location. The old repository is read-only now. For more detailed instructions on migrating to your new repo, please see https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20F A Q / -- SourceForge.net<http://SourceForge.net> has sent this mailing to you as a registered user of the SourceForge.net<http://SourceForge.net> site to convey important information regarding your SourceForge.net<http://SourceForge.net> account or your use of SourceForge.net<http://SourceForge.net> services. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support ------------------------------------------------------------------------ - - ---- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.cl k t rk _______________________________________________ Bigdata-developers mailing list Big...@li...<mailto:Big...@li...> https://lists.sourceforge.net/lists/listinfo/bigdata-developers |
|
From: Mike P. <mi...@sy...> - 2014-02-19 20:33:38
|
* SVN:https://svn.code.sf.net/p/bigdata/code/(read/write) On Feb 19, 2014, at 1:32 PM, "Bryan Thompson" <br...@sy...<mailto:br...@sy...>> wrote: Which URL did you use to checkout from svn? On Feb 19, 2014, at 3:00 PM, "Mike Personick" <mi...@sy...<mailto:mi...@sy...>> wrote: Yes, I read the notice carefully, and I did a fresh checkout from the new URL. I cannot commit against that fresh checkout. On 2/19/14 12:55 PM, "Bryan Thompson" <br...@sy...<mailto:br...@sy...>> wrote: You need to do a new checkout from the new SVN. Did you do that? Then you have to migrate any changes. That is why Martyn sent out notice before the change overŠ. Bryan On 2/19/14 2:50 PM, "Mike Personick" <mi...@sy...<mailto:mi...@sy...>> wrote: I cannot commit using my sourceforge credentials. On 2/19/14 6:50 AM, "Bryan Thompson" <br...@sy...<mailto:br...@sy...>> wrote: FYI, the new SVN repository should be ready for use. Thanks, Bryan On 2/19/14 8:15 AM, "SourceForge.net<http://SourceForge.net>" <nor...@in...<mailto:nor...@in...>> wrote: Your code repository in upgraded project bigdata is now ready for use. Old repository url: http://bigdata.svn.sourceforge.net/svnroot/bigdata New repository checkout command: svn checkout --username=thompsonbry svn+ssh://tho...@sv.../p/bigdata/code/ bigdata-code You should do a checkout using the new repository location. The old repository is read-only now. For more detailed instructions on migrating to your new repo, please see https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20F A Q / -- SourceForge.net<http://SourceForge.net> has sent this mailing to you as a registered user of the SourceForge.net<http://SourceForge.net> site to convey important information regarding your SourceForge.net<http://SourceForge.net> account or your use of SourceForge.net<http://SourceForge.net> services. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support ------------------------------------------------------------------------ - - ---- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.cl k t rk _______________________________________________ Bigdata-developers mailing list Big...@li...<mailto:Big...@li...> https://lists.sourceforge.net/lists/listinfo/bigdata-developers |
|
From: Bryan T. <br...@sy...> - 2014-02-19 20:32:12
|
Which URL did you use to checkout from svn? > On Feb 19, 2014, at 3:00 PM, "Mike Personick" <mi...@sy...> wrote: > > Yes, I read the notice carefully, and I did a fresh checkout from the new > URL. I cannot commit against that fresh checkout. > > >> On 2/19/14 12:55 PM, "Bryan Thompson" <br...@sy...> wrote: >> >> You need to do a new checkout from the new SVN. Did you do that? Then >> you have to migrate any changes. That is why Martyn sent out notice >> before the change overŠ. >> >> Bryan >> >>> On 2/19/14 2:50 PM, "Mike Personick" <mi...@sy...> wrote: >>> >>> I cannot commit using my sourceforge credentials. >>> >>> >>>> On 2/19/14 6:50 AM, "Bryan Thompson" <br...@sy...> wrote: >>>> >>>> FYI, the new SVN repository should be ready for use. >>>> Thanks, >>>> Bryan >>>> >>>> On 2/19/14 8:15 AM, "SourceForge.net" >>>> <nor...@in...> >>>> wrote: >>>> >>>>> Your code repository in upgraded project bigdata is now ready for use. >>>>> >>>>> Old repository url: http://bigdata.svn.sourceforge.net/svnroot/bigdata >>>>> >>>>> New repository checkout command: svn checkout --username=thompsonbry >>>>> svn+ssh://tho...@sv.../p/bigdata/code/ bigdata-code >>>>> >>>>> You should do a checkout using the new repository location. The old >>>>> repository is read-only now. >>>>> >>>>> For more detailed instructions on migrating to your new repo, please >>>>> see >>>>> https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20F >>>>> A >>>>> Q >>>>> / >>>>> >>>>> -- >>>>> SourceForge.net has sent this mailing to you as a registered user of >>>>> the SourceForge.net site to convey important information regarding >>>>> your SourceForge.net account or your use of SourceForge.net services. >>>>> If you have concerns about this mailing please contact our Support >>>>> team per: http://sourceforge.net/support >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> - >>>> - >>>> ---- >>>> Managing the Performance of Cloud-Based Applications >>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >>>> Read the Whitepaper. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.cl >>>> k >>>> t >>>> rk >>>> _______________________________________________ >>>> Bigdata-developers mailing list >>>> Big...@li... >>>> https://lists.sourceforge.net/lists/listinfo/bigdata-developers > |
|
From: Mike P. <mi...@sy...> - 2014-02-19 20:05:53
|
Martyn, I have successfully logged into the trac application using my mi...@sy... OpenId credentials. Please run whatever scripts need to be run to get me access to my old tickets, or let me know what further steps I need to take on my own. Thanks, Mike From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Wednesday, February 19, 2014 12:58 PM To: Mike Personick <mi...@sy...<mailto:mi...@sy...>>, Martyn Cutcher <ma...@sy...<mailto:ma...@sy...>>, "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Bigdata Allura Migration You need to clear out your cookies for the last hour. Then you can choose a different login. Bryan From: Mike Personick <mi...@sy...<mailto:mi...@sy...>> Date: Wednesday, February 19, 2014 2:55 PM To: Bryan Thompson <br...@sy...<mailto:br...@sy...>>, Martyn Cutcher <ma...@sy...<mailto:ma...@sy...>>, "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Bigdata Allura Migration I logged in using my gmail account credentials, which I do not want to use, I want to use my systap credentials. Now when I logout and try to log back in, there is no way for me to change which open id account I want to log in under, it just goes straight to the gmail credentials. From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Wednesday, February 19, 2014 12:51 PM To: Mike Personick <mi...@sy...<mailto:mi...@sy...>>, Martyn Cutcher <ma...@sy...<mailto:ma...@sy...>>, "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Bigdata Allura Migration Martyn has to do a migration for your username. What you do is login with Google's OpenID. Martyn has scripts to port your OpenID login into the wiki and trac systems. I do not know if he has already run those scripts for you, or if you need to login before he can run the script. I think that it might be the latter, in which case you will need to let him know that you have logged in and then he can do the magic script dance for you. Bryan From: Mike Personick <mi...@sy...<mailto:mi...@sy...>> Date: Wednesday, February 19, 2014 2:49 PM To: Bryan Thompson <br...@sy...<mailto:br...@sy...>>, Martyn Cutcher <ma...@sy...<mailto:ma...@sy...>>, "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Bigdata Allura Migration I'm not exactly sure I understand how to log in to the new trac such that I still have access to my old tickets under my sourceforge user name. From: Bryan Thompson <br...@sy...<mailto:br...@sy...>> Date: Wednesday, February 19, 2014 5:51 AM To: Martyn Cutcher <ma...@sy...<mailto:ma...@sy...>>, "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: Re: [Bigdata-developers] Bigdata Allura Migration We have done the basic project migration. Developers probably need to check out a CLEAN COPY of bigdata from the new SVN repository (see https://sourceforge.net/projects/bigdata/). If you have any uncommitted edits, then will need to be applied to that clean checkout before they can be committed to the new SVN repository location! Thanks, Bryanb From: Martyn Cutcher <ma...@sy...<mailto:ma...@sy...>> Date: Tuesday, February 18, 2014 10:50 AM To: "big...@li...<mailto:big...@li...>" <big...@li...<mailto:big...@li...>> Subject: [Bigdata-developers] Bigdata Allura Migration Hi all, Very soon we will be migrating the Bigdata sourceforge account to the new Allura platform. We have taken the decision to continue to use the existing Trac issue management system and MediaWiki, but will now host these applications ourselves. We have set up the applications using a server on Amazon EC2. One thing that will change is the user management previously integrated with sourceforge. Instead we have configured the new applications to use OpenID. Users will login using their Google account. This leads to a few issues for existing users, since in some cases we need to be able to identify the new OpenID users with their original accounts. The URLs to access the applications are: http://trac.bigdata.com http://wiki.bigdata.com Most users can simply login to both using an OpenID account - we have restricted the trac login to a required Google account and are aware of the inconsistency of login options between the wiki and trac, but please bear with us while we try and iron out the wrinkles. If you have previously created or commented on trac tickets, or edited wiki articles then we will need to run some scripts to tie your new OpenID user to the existing trac or wiki user. If so then please email me at ma...@sy...<mailto:ma...@sy...> with your old and new user names for trac and/or wiki as appropriate and I will try to get your configuration updated ASAP. Your patience will be greatly appreciated! cheers - Martyn Preliminary Schedule - Wednesday 19th February Trac and Wiki 1) 0800 GMT Freeze new Ticket creation and updates on Trac Freeze updates to Wiki Migrate Trac and Wiki data 2) 1200 GMT Trac and Wiki will be available from new locations for read access 3) Developers should login to trac.bigdata.com and wiki.bigdata.com and mail me their user names for joining. Allura SVN A) 1200 GMT Freeze any updates to SVN. Commit local changes to developer sub-branches where possible. B) 1400 GMT commence migration of SVN to Allura C) Notification of new SVN URLs will be emailed when ready |
|
From: Mike P. <mi...@sy...> - 2014-02-19 20:00:28
|
Yes, I read the notice carefully, and I did a fresh checkout from the new URL. I cannot commit against that fresh checkout. On 2/19/14 12:55 PM, "Bryan Thompson" <br...@sy...> wrote: >You need to do a new checkout from the new SVN. Did you do that? Then >you have to migrate any changes. That is why Martyn sent out notice >before the change overŠ. > >Bryan > >On 2/19/14 2:50 PM, "Mike Personick" <mi...@sy...> wrote: > >>I cannot commit using my sourceforge credentials. >> >> >>On 2/19/14 6:50 AM, "Bryan Thompson" <br...@sy...> wrote: >> >>>FYI, the new SVN repository should be ready for use. >>>Thanks, >>>Bryan >>> >>>On 2/19/14 8:15 AM, "SourceForge.net" >>><nor...@in...> >>>wrote: >>> >>>>Your code repository in upgraded project bigdata is now ready for use. >>>> >>>>Old repository url: http://bigdata.svn.sourceforge.net/svnroot/bigdata >>>> >>>>New repository checkout command: svn checkout --username=thompsonbry >>>>svn+ssh://tho...@sv.../p/bigdata/code/ bigdata-code >>>> >>>>You should do a checkout using the new repository location. The old >>>>repository is read-only now. >>>> >>>>For more detailed instructions on migrating to your new repo, please >>>>see >>>>https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20F >>>>A >>>>Q >>>>/ >>>> >>>>-- >>>>SourceForge.net has sent this mailing to you as a registered user of >>>>the SourceForge.net site to convey important information regarding >>>>your SourceForge.net account or your use of SourceForge.net services. >>>>If you have concerns about this mailing please contact our Support >>>>team per: http://sourceforge.net/support >>> >>> >>>------------------------------------------------------------------------ >>>- >>>- >>>---- >>>Managing the Performance of Cloud-Based Applications >>>Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >>>Read the Whitepaper. >>>http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.cl >>>k >>>t >>>rk >>>_______________________________________________ >>>Bigdata-developers mailing list >>>Big...@li... >>>https://lists.sourceforge.net/lists/listinfo/bigdata-developers >> > |
27 messages has been excluded from this view by a project administrator.
