Hello cf-dev,

Loggregator has been working on some improvements to the NOAA library.

The recommended way to create a NOAA consumer is now consumer.New(...)
under the consumer package instead of the legacy method of
noaa.NewConsumer(...). consumer.Consumer has some minor changes from
noaa.Consumer:

- Methods that accepted channels now return read-only channels, which the
consumer will close once it is done with them

- There is no Closed method.

- The new consumer can be used for multiple websocket calls, and all
previous connections (and the corresponding returned channels) will be
closed when Close is called.


The consumer within the noaa package is now deprecated and will be removed
in the near future.

We also added friendly reminders and warnings in the README
<https://github.com/cloudfoundry/noaa#deprecation> and stderr
<https://github.com/cloudfoundry/noaa/blob/master/consumer.go#L59> output.

Thanks.
Loggregator Team

Hi all,

We'd like to let you know that in the next week we'll be scheduling work to
update the default version of Ruby in the Ruby Buildpack from 2.2.x to
2.3.x. This change only affects application that don't specify the version
of Ruby in the Gemfile.

Please let us know if this is an undesired change. Also, please keep in
mind that you can always force the buildpack to use a specific version of
ruby by adding the following line to your `Gemfile`:

```
ruby "2.2.4"
```

Cheers,

JS

On Tue, May 3, 2016 at 3:23 AM, Bala Murugan <balamurugan151187(a)gmail.com>
wrote:

Hi,

We are trying to push an buildpack using cf creat-buildpack command and
below are the CF_TRACE logs

REQUEST: [2016-05-03T06:20:46Z]
PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits HTTP/1.1
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data;
boundary=be0b00f857ab0afc2960021bde74f00694661d064034c3901d96b022952f
User-Agent: go-cli 6.16.1+924508c / linux


[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading

RESPONSE: [2016-05-03T06:21:46Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

Its getting failed. Can you please suggest us on how to trouble shoot it..

The time stamp on the request and response are exactly 60 seconds apart.
Do you have any timeouts that are set to 60 seconds? Perhaps on your load
balancer?

Dan

Hello,

Hope you are doing well.

I wanted to bring to your attention the latest SNS Research report in which you might be interested, " The Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals and Forecasts."

I believe this report will be highly applicable for you. If you would like to see the report sample or have any questions, please let me know.

Report Information:

Release Date: May 2016
Number of Pages: 219

Report Overview:

While wearable technology has been utilized in vertical sectors such as the military and healthcare industries for many years, ongoing advances have triggered a major resurgence of the concept, particularly among the consumer community. Key enabling technologies including low cost sensors, wireless connectivity, active materials and energy have converged to make wearable technology mainstream.

With the continued miniaturization of enabling technologies, wearable devices have hit the mass market in a diverse variety of form factors, ranging from glasses to even jewelry.

Driven by the ability to interconnect with key modern trends of healthcare, fitness, messaging and socialization, the wearable technology ecosystem is attracting significant levels of interest. Companies as varied as smartphone OEMs, mobile operators, health insurers and retailers are circling the ecosystem alongside tiny startups, all vying for a stake.

SNS Research estimates that wearable device shipments will grow at a CAGR of 29% between 2016 and 2020. By 2020, wearable devices will represent a market worth $40 Billion with over 240 Million annual unit shipments.

The "Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals & Forecasts" report presents an in-depth assessment of the wearable technology ecosystem including key market drivers, challenges, investment potential, consumer & vertical market opportunities, use cases, future roadmap, value chain, case studies, vendor market share and strategies. The report also presents forecasts for wearable device shipments and revenue from 2016 through to 2030. The forecasts are further segmented for 7 device form factor submarkets, 7 vertical markets, 6 regions and 73 countries.

The report comes with an associated Excel datasheet suite covering quantitative data from all numeric forecasts presented in the report.


Key Findings:

The report has the following key findings:
SNS Research estimates that wearable device shipments will grow at a CAGR of 29% between 2016 and 2020. By 2020, wearable devices will represent a market worth $40 Billion with over 240 Million annual unit shipments.
Leading smartphone OEMs, Apple and Samsung, are replicating their success in the OS powered smart watch arena with a combined market share of nearly 75%.
As wearable device OEMs seek to minimize dependence on hardware sales, new business models are beginning to emerge, particularly in the enterprise space. For example, specialist vendors such as Catapult are offering subscription based services to sports teams, which combine wearable sensors, cloud-based software and analytics.
SNS Research estimates that wearable devices will help mobile operators drive over $13 Billion in service revenue by the end of 2020, following a CAGR of nearly 32% between 2016 and 2020.
The market is ripe for acquisitions of pure-play wearable technology startups, as competition heats up between consumer and vertical centric OEMs.

Topics Covered:

The report covers the following topics:
Wearable technology ecosystem
Market drivers and barriers
Enabling technologies and operating systems for wearable devices
Standardization and regulation landscape
Wearable technology industry roadmap and value chain
Assessment of vertical market opportunities and use cases for consumer, healthcare, professional sports, retail & hospitality, military, public safety and 8 other verticals
Case studies of wearable technology deployments
Company profiles and strategies of over 440 wearable technology ecosystem players
Wearable device vendor market share
Prospects of smartphone OEMs and wireless chipset suppliers in the wearable technology ecosystem
Impact of 5G, NB-IoT and LTE Direct on wearable technology
Strategic recommendations for enabling technology providers, wearable device OEMs, vertical market players, application developers and mobile operators
Market analysis and forecasts from 2016 till 2030

Forecast Segmentation:
Market forecasts are provided for each of the following submarkets and their categories:
Vertical Submarkets
Consumer
Healthcare
Professional Sports
Retail & Hospitality
Military
Public Safety
Others
Form Factor Submarkets
Smart Bands
Smart Watches
Smart Glasses
Smart Clothing
Smart Jewelry
Heads-up Displays
Others
Regional Markets
Asia Pacific
Eastern Europe
Latin & Central America
Middle East & Africa
North America
Western Europe
Country Markets
73 Country level markets: Algeria, Argentina, Australia, Austria, Bangladesh, Belarus, Belgium, Bolivia, Bosnia & Herzegovina, Brazil, Bulgaria, Canada, Chile, China, Colombia, Croatia, Czech Republic, Denmark, Ecuador, Egypt, Finland, France, Germany, Greece, Hong Kong, Hungary, India, Indonesia, Ireland, Israel, Italy, Japan, Kenya, Luxembourg, Malaysia, Mexico, Morocco, Netherlands, New Zealand, Nigeria, Norway, Pakistan, Paraguay, Peru, Philippines, Poland, Portugal, Qatar, Romania, Russia, Saudi Arabia, Serbia, Singapore, Slovakia, South Africa, South Korea, Spain, Sudan, Sweden, Switzerland, Taiwan, Tanzania, Thailand, Tunisia, Turkey, UAE, UK, Ukraine, Uruguay, USA, Uzbekistan, Venezuela and Vietnam

Key Questions Answered:

The report provides answers to the following key questions:
How big is the wearable technology ecosystem?
How is the ecosystem evolving by segment and region?
What will the market size be in 2020 and at what rate will it grow?
What trends, challenges and barriers are influencing its growth?
Who are the key wearable device vendors and what are their strategies?
How much are vertical enterprises investing in wearable devices?
What opportunities exist for wireless chipset suppliers in the wearable technology ecosystem?
How can mobile operators capitalize on the growing popularity of smart watches, fitness bands, smart glasses and other wearable devices?
Which countries, regions and verticals will see the highest percentage of wearable device shipments?
Which sports category will see the highest level of wearable technology integration?

Report Pricing:

Single User License: USD 2,500

Company Wide License: USD 3,500


Ordering Process:

Please contact Emily Hall at e.hall(a)snscommunication.com

And provide the following information:
Report Title:
Report License (Single User/Company Wide):
Name:
Email:
Job Title:
Company:

Please contact me if you have any questions, or wish to purchase a copy.

I look forward to hearing from you.

Kind Regards,

Emily Hall

Sales Director
Signals and Systems Research
Email: e.hall(a)snscommunication.com
Address: Reef Tower
Jumeirah Lake Towers
Sheikh Zayed Road
Dubai, UAE

To unsubscribe, please reply to this email with unsubscribe in the subject line.

So to be precise, my APP is a jetty based application, it includes jetty
jars and related jetty configuration files.
When this application is deployed on ubuntu (Non-CF) environment, we can
get expect status message we customized.
But when deploying to CF, the customized message is always changed to the
standard status message.
Since all the jetty jars and configuration files are included in our APP
already, so there should no difference in jetty part.

That's why we suspect the problem is in CF related things, but really got
no clue where is it.
We do have some code related to this behavior, and since it's standard
servlet behavior, so I think we should supports it?
http://www.java2s.com/Code/JavaAPI/javax.servlet.http/HttpServletResponsesendErrorintarg0Stringarg1.htm


Attached is one simple jetty based application, when I run it locally I can
get my customized message.

wget http://localhost:8080/hello
--2016-05-03 18:15:22-- http://localhost:8080/hello
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 403 my customized 413 error message
2016-05-03 18:15:22 ERROR 403: my customized 413 error message.

When pushing to CF, I still got the standard message.
HTTP request sent, awaiting response... 403 Forbidden
2016-05-03 18:18:46 ERROR 403: Forbidden.

Thanks,
Stanley

Hi,

We are trying to push an buildpack using cf creat-buildpack command and below are the CF_TRACE logs

REQUEST: [2016-05-03T06:20:46Z]
PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits HTTP/1.1
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data; boundary=be0b00f857ab0afc2960021bde74f00694661d064034c3901d96b022952f
User-Agent: go-cli 6.16.1+924508c / linux


[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading

RESPONSE: [2016-05-03T06:21:46Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

Its getting failed. Can you please suggest us on how to trouble shoot it..

Thanks,
Bala

Hi,

We are trying to push an buildpack using cf creat-buildpack command and below are the CF_TRACE logs

REQUEST: [2016-05-03T06:20:46Z]
PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits HTTP/1.1
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data; boundary=be0b00f857ab0afc2960021bde74f00694661d064034c3901d96b022952f
User-Agent: go-cli 6.16.1+924508c / linux


[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading

RESPONSE: [2016-05-03T06:21:46Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

Its getting failed. Can you please suggest us on how to trouble shoot it..

Thanks,
Bala

Thanks for investigation.

Actually my APP is a jetty based application, the APP releases included all required jetty jar and configuration files, so it should not related to this tomcat setting?

As tomcat can reproduce my issue easily so I took tomcat for example.

Agree ! That's awesome !

Envoyé de mon iPhone

This is awesome! Thanks guys!

Mike

Agree with Dan.

Currently most APM vendors use the VCAP_APPLICATION env variable for
mapping and keeping track of a specific instance using the instance guid,
instance index, app guid fields. Changing it would affect the buildpacks
and extensions.

Sample for AppD APM:
default_node_name: $(ruby -e "require 'json' ; a =
JSON.parse(ENV['VCAP_APPLICATION']);

puts \"#{a['application_name']}:#{a['instance_index']}\"")
Some of these complex expressions might become simpler, as long as the
values still come through with different names.

So, as long as the current set of values continue to exist and either in
flat or easy to grab from ENV, I am okay with that.

thanks,
Sabha

--
Sabha Parameswaran
Platform Engineering, Cloud Foundry
Pivotal, Inc.
m: +1 (415) 244-5554

I have a few customers that grab that instance index to aid in monitoring
and logging and to self identify in certain situations. Is there an issue
with continuing to expose the instance index?

I don't know anything about v2 vs v3 apis. Would VCAP_APPLICATION continue
to work for apps pushed using the v2 api and only have this new value if
pushed using the v3 api?

Mike

I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick

While I dont use this directly, my first reaction is some libraries such as
Spring Cloud Connectors depend on this to identify that an app is running
in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share? Are
there Cloud Foundry operators / users that would like to get rid of this
all together? Our current plan was to do something like below, but wanted
to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick

Hi Stanley,

We can reproduce your issue when we push your .war file to a CF running on bosh-lite. We actually also see this same behavior when we run the .war file on a local Tomcat with default configuration . So, we believe the issue is due to tomcat configuration - your local tomcat probably has different configuration than the one provided by the buildpack, and what we see on an out-of-the-box tomcat installation.

You can see the java buildpack's tomcat configuration here: https://github.com/cloudfoundry/java-buildpack/blob/master/resources/tomcat/conf/server.xml

The behavior you're requesting is unusual, so the java buildpack does not support it (it is nothing to do with dea/diego) so you have a few options. If you really need this behavior, you have a few options:
- fork the buildpack and change server.xml to your needs
- use spring boot which allows you to fully configure the servlet container

Thanks,
Rob Dimsdale & David Sabeti
CF Release Integration
Pivotal

Hi there!

We wanted to let you know of a significant feature addition to the PHP
buildpack. Thanks to Daniel Mikusa and the Buildpacks team the PHP
Buildpack now has support for persistent sessions in both Redis and
Memcached.

Check out the documentation here
<https://github.com/cloudfoundry/php-buildpack/blob/develop/docs/sessions.md>
and give it a spin.

hello, I tried with latest cf/diego release.
I still can reproduce the issue.
I am using all things provided by CF without any customization.
I just push my servlet APP and access it from command line.(You can find it in a previous reply in this thread)

wget http://test.[APP domain]/test
--2016-05-02 03:28:15-- http://test.[APP domain]/test
Resolving test.[APP domain] (test.[APP domain])... 152.190.109.xx
Connecting to test.[APP domain] (test.[APP domain])|152.190.109.xx|:80... connected.
HTTP request sent, awaiting response... 414 Request URI Too Long
2016-05-02 03:28:15 ERROR 414: Request URI Too Long.

Here the error message is "Request URI Too Long", which is the standard one, but my customized message "my customized 414 error message".


+---------------------------------------------+---------------+---------+--------------------------------------+
| Name | OS | Version | CID |
+---------------------------------------------+---------------+---------+--------------------------------------+
| bosh-warden-boshlite-ubuntu-trusty-go_agent | ubuntu-trusty | 3147* | 0636a704-8ac9-44a8-7f21-793f17310298 |
+---------------------------------------------+---------------+---------+--------------------------------------+

+-------------------+-----------------+-------------+
| Name | Versions | Commit Hash |
+-------------------+-----------------+-------------+
| cf | 236+dev.1* | 9a550e9d+ |
| diego | 0.1468.0+dev.1* | a54eeaf4+ |
| docker | 26* | 7fabb47c+ |
| etcd | 45* | 96dab618+ |
| garden-linux | 0.337.0* | a7d9ddac |
+-------------------+-----------------+-------------+

buildpack position enabled locked filename
staticfile_buildpack 1 true false staticfile_buildpack-cached-v1.3.6.zip
java_buildpack 2 true false java-buildpack-v3.7.zip
ruby_buildpack 3 true false ruby_buildpack-cached-v1.6.16.zip
nodejs_buildpack 4 true false nodejs_buildpack-cached-v1.5.12.zip
go_buildpack 5 true false go_buildpack-cached-v1.7.5.zip
python_buildpack 6 true false python_buildpack-cached-v1.5.5.zip
php_buildpack 7 true false php_buildpack-cached-v4.3.10.zip
binary_buildpack 8 true false binary_buildpack-cached-v1.0.1.zip
admin_console_buildpack 9 true false admin_console_buildpack-cached-v1.6.12.zip

Hi,

Mod_security [1] is a flexible opensource web application firewall, which
runs configureable rules to detect and possible filter malicious incoming
HTTP requests received (XSS, SQL injection ....). Orange is preparing a PR
to add support for mod_security in the php_buildpack [2].

I'd be interested to hear if there is interest for such support in the
community and specific requirements/refinements over Orange's initial work
to be done.

Thanks in advance,

Guillaume.

ps: A possible future integration could also be packaged as a
fully-brokered route service in the future, which could be applying to all
buildpacks. As a 1st step, we focussed our effort to httpd within php
buildpack, mainly to avoid the added network hops implied by the
fully-brokered service

[1] https://www.modsecurity.org
[2] https://github.com/cloudfoundry/php-buildpack/issues/144

If possible add more logging or increase logging levels. Not sure what
language / runtime you're using, but you might be able to add an exit hook
or some code that is guaranteed to run before your app exits and use that
to dump more info.

If CF were shutting down your app for some reason, you would see a SIGTERM
sent followed by a SIGKILL roughly 10 seconds later (if your app doesn't
gracefully exit first). I don't think that's what is happening here, but
you could catch the SIGTERM and log a message to check. CF would really
only do this if the cell that your app is running on were being shut off
(like during an upgrade). Then it would restart your app automatically on
another cell.

The other case could be that you're exceeding your MEMORY_LIMIT. I don't
think that's happening as I believe Diego logs something that specifically
says when you run out of memory (like `Exited with status 255 (out of
memory)`).

Dan