pratiktest
10/5/2016 - 12:38 PM

work.md

work.md
content_copyfile_download
  • Rendered
  • Source

Jetty http/2

  • jetty has client and server implementation for http2
  • requirement for running http2 is jdk8 +, ALPN (Application Layer Protocol Negotiation)
  • server deployed over SSL(TLS transport layer) advertises http/2 protocol
  • to start ALPN, start the JVM as java -Xbootclasspath/p:path_to_alpn_boot_jar

ALPN support

  • Client should know ALPN, server should know ALPN for http2 to work. If client does not support ALPN, jetty will default to http/1.1

Jetty demo, starting jetty as http2

  • download jetty
  • export JETTY_HOME = location for jetty folder (the folder where you do tar -xvzf jetty_distribution
  • export JETTY_HOME = ~/software/jetty-distribution-9.3.12.v20160915
  • or cd ~/software/jetty-distribution-9.3.12.v20160915

java -jar start.jar --add-to-startd=http,https,deploy
  • this command initializes http(runs on port 8080) , https(runs on port 8443). Https module downloads a demo keystore file with a self signed certificate, This has to be replaced with actual certificate from CA for real deployment
  • to add http2 to demo base it is just matter of enabling http2 module
java -jar $JETTY_HOME/start.jar --add-to-startd=http2

Start Http2 server


java -jar $JETTY_HOME/start.jar
  • you will see following output
main: Started ServerConnector@4590c9c3{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}

Started ServerConnector@2fd66ad3{SSL,[ssl, alpn, h2, h2-17, h2-16, h2-15, h2-14, http/1.1]}{0.0.0.0:8443}
  • This shows port 8080 supports of http1, while 8443 supports ssl with different ALPN negotiations to select between different versions of http/2
  • A browser can now be pointed at https://localhost:8443/ and if it supports HTTP/2 then it will be used (often indicated by a lightening bolt icon in the address bar)
  • to support http2 on plain text connector do
java -jar $JETTY_HOME/start.jar --add-to-startd=http2c
  • no browser currently supports plain text http2

difference between put and post

  • put is like a file upload. It only affects that URI. eg put an item, will create an item if it dosent exists or update an item if it exists. If same request is made again it will only affect that item and it will create no change on the server(idempotent).

  • post can have any effect on server. eg we post an item and it may cause other changes to another uri like user. Posting an item may change the state of the user and other URI on server or cause some processing which changes different URI (resource). POST is not idempotent since we cannot know the state of the server. Multiple post request may produce different results

work links

mysql vs nosql

  • mysql data integrity is maintained using foreign keys. We know the schema upfront then we can relate the tables using foreign keys and it can be enforced that a foreign key is present to depict a relationship
  • the above cannot be enforced in nosql
  • transactions where we update multiple tables at a time and if one fails everuthing rolls back is not enforced in no sql
  • data denormalization may cause the nosql queries to run faster but may cause data redundancies and some slowness in other queries
  • eg getting data might be fast as data is replicated and no table joins is required. but updating data might be slow as we may have to traverse and update all the entries in collection.

New sql

  • newsql use sql as their primary interface and support relational data model
  • they are targeted for
    • applications with large number of transactions
    • are short lived (like web apps come within 1 sec)
    • touch small subset of data using index lookups (no joins) *no sql applications are good for logging ..quicki index lookups, hackweek projects..get something up and running fast

http1

  • http1 we could not create multiple connections per domain

  • hence we started using domain sharding

  • like all images served from ebay.img domain.. all css from ebay.css

  • this enabled browsers to create multiple connections since thay are different domains

  • with http1.1 pipelining was introduced

  • this enabled browsers to pipeline calls like.. lets say we want 10 css files

  • we can file multiple calls and then they are like fire and forget

  • they are then collected back in a sequence

  • if one call is slow then all the subsequent calls in pipeline become slow

  • also pipelining is not supported by all servers and is difficult to deploy on servers

  • with http2 we have multiplexing

  • now a bidirectional connection is kept open forever (of course it will have some timeout for inatctivity)

  • and if we need 10 css files ..they can be requested in parallel. ,ultiple request and response can be in flight at same time.

  • this has enabled one connection only per origin with request ao multiple resources

Mirrors and problem with jenkins:

  • mirrors are just read only file serving location which gets updated
  • Ecentral is a mirror for nexus repositories
  • in jenkins machine we have a settings.xml somewhere which states that we can connect to only Ecentral and other repo will be directed to maven central
  • however this is a problem if we want to use jars from other open source nexus repo or other maven repo
  • to workaround this we need to checkin our settings.xml and tell jenkins to run this settings.xml Manage Jenkins -> configure.. or we can set this in job config too