ezhov-da

<subsystem xmlns="urn:jboss:domain:undertow:1.0">
  ...
  <server name="default-server">
      <http-listener name="default" socket-binding="http" max-post-size="20971520"/>
      <host name="default-host" alias="localhost">
          <location name="/" handler="welcome-content"/>
      </host>
  </server>
  ...
</subsystem>

ezhov-da

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

ezhov-da

Synopsis

At the top of the file there should be a short introduction and/ or overview that explains what the project is. This description should match descriptions added for package managers (Gemspec, package.json, etc.)

Code Example

Show what the library does as concisely as possible, developers should be able to figure out how your project solves their problem by looking at the code example. Make sure the API you are showing off is obvious, and that your code is short and concise.

Motivation

ezhov-da

Configure Git to use a proxy

In Brief

You may need to configure a proxy server if you're having trouble cloning or fetching from a remote repository or getting an error like unable to access '...' Couldn't resolve host '...'.

Consider something like:

ezhov-da

Best efforts 1 Phase commit

This is a non-XA pattern that involves a synchronized single-phase commit of a number of resources. Because the 2PC is not used, it can never be as safe as an XA transaction, but is often good enough if the participants are aware of the compromises. The basic idea is to delay the commit of all resources as late as possible in a transaction so that the only thing that can go wrong is an infrastructure failure (not a business-processing error). Systems that rely on Best Efforts 1PC reason that infrastructure failures are rare enough that they can afford to take the risk in return for higher throughput. If business-processing services are also designed to be idempotent, then little can go wrong in practice.

Scenarios

Consider a jms based service, where there is an inbound Queue manager (QM1), an outbound queue manager (QM2) and a database (DB). Here are the scenarios that I would like to cover using Best efforts 1 PC commit process:

Happy path

1. Start MQ transaction on QM1 2

ezhov-da

Common Options

-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.

-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).

-c, --cookie-jar <file name> File to save response cookies to.

ezhov-da

#!/usr/bin/env python

import os
import sys
import requests
import argparse
import json
import time

pulp_user = 'admin'

ezhov-da

Run commands on remote Docker host

This is how to connect to another host with your docker client, without modifying your local Docker installation or when you don't have a local Docker installation.

Enable Docker Remote API

First be sure to enable the Docker Remote API on the remote host.

This can easily be done with a container.
For HTTP connection use jarkt/docker-remote-api.

ezhov-da

const N_WORKERS = 5

class Content
class Location
class Reference {
    fun resolveLocation(): Location = TODO()
}

data class LocContent(val location: Location, val content: Content)

ezhov-da

Use: for testing against email regex
ref: http://codefool.tumblr.com/post/15288874550/list-of-valid-and-invalid-email-addresses


List of Valid Email Addresses

[email protected]
[email protected]
[email protected]
[email protected]