I'm not able to find a way to simply start and stop a Cloud SQL instance using java mysql admin-api.
I found this official google documentation that explain how to start and stop the Cloud SQL instance via gcloud: https://cloud.google.com/sql/docs/mysql/start-stop-restart-instance But I'm not able to obtain the same things via java using mysql admin-api,
Anybody can help me?
Generally, the Cloud SQL Admin API for Java is used for operations such as the one you are looking for. If you are using Maven, you can add the library to your project adding the following lines of code to the pom.xml configuration file:
<project>
<dependencies>
<dependency>
<groupId>com.google.apis</groupId>
<artifactId>google-api-services-sqladmin</artifactId>
<version>v1beta4-rev48-1.23.0</version>
</dependency>
</dependencies>
</project>
EDIT:
As far as I can see in the documentation, the underlying API uses the Instance.Patch method for starting and stopping instances, although I cannot find any specific information about how to do it. However, you can find more relevant information yourself in the Instances:Patch page. I will keep looking for more information and in case I find something relevant, I will post a comment to this answer below.
EDIT 2:
I have been performing some tests using the Google APIs Explorer, using the PROJECT_ID, SQL_INSTANCE_ID and a JSON body such as this one:
{
"settings": {
"activationPolicy": "YOUR_PREFERED_STATE"
}
}
According to the documentation:
The activation policy specifies when the instance is activated; it is
applicable only when the instance state is RUNNABLE. Valid values:
ALWAYS: The instance is on, and remains so even in the absence of
connection requests. NEVER: The instance is off; it is not activated,
even if a connection request arrives. ON_DEMAND: First Generation
instances only. The instance responds to incoming requests, and turns
itself off when not in use. Instances with PER_USE pricing turn off
after 15 minutes of inactivity. Instances with PER_PACKAGE pricing
turn off after 12 hours of inactivity.
I have tried running the API with the NEVER and ALWAYS states, and my Cloud SQL instance stopped and started accordingly. So in your case, and going back to the Admin API for Java, you should be looking at the Settings of your instance, specifically at this method:
public Settings setActivationPolicy(java.lang.String activationPolicy)
Changing the Activation Policy to NEVER or ALWAYS should be what you need here, although you can have a look at the other possible instance states in case they fit your requirements better.
Related
My target is to build a GraphQL server on Spring with (1) GraphiQL IDE (2) dynamic GraphQL schema at run-time. My GraphQL engine is GraphQL-Java.
In my first try, I use graphql-java-spring-boot-starter-webmvc and graphiql-spring-boot-starter.
Both the GraphQL server and the GraphiQL work well.
However, under the graphql-java-spring-boot-starter-webmvc framework, a #Bean of GraphQL class is needed. In this bean, the schema is loaded when the server starts so it could not been updated.
In my second try, I don't use graphql-java-spring-boot-starter-webmvc. Instead, I choose spring-boot-starter-web to start the web server and define my own RestController. This is easy to update the GraphQL instance. But I don't find a way to integrate with GraphiQL. I googled GraphiQL+Spring but all solutions are with graphql-java-spring-boot-starter.
Appreciate if anyone could provide me an idea on either approach.
It can be enabled in properties:
graphql.graphiql.enabled=true
It is accessible via the root url +/graphiql example http://localhost:8080/graphiql
You can find a good detailed example here : https://github.com/NoorKrichen/GraphQL-Spring-Boot-Example
Do you have a sample of your setup in git?
It sounds like some configuration problem. But naturally using graphql-java-spring-boot-starter-webmvc all your *.graphql schemas should be picked up in the configured schema resource path. check if you have the path set in your application.yml or if your schema is in the configured path if its already set or by default.
On your second point: "I googled GraphiQL+Spring but all solutions are with graphql-java-spring-boot-starter."
This makes sense for quick guides and demos as using Springboot the plumbing is somehow hidden away from you so that you can focus on the technology at hand being demo'd in this case GraphQl.
On GraphiQL:
Sounds like you are intending to have this embedded with your application, you may not want to do so in production. Depending on your use case there are many other alternatives that are standalone and gives you all the functionality of GraphiQL plus more e.g Altair Graphql Client and Insomnia to name a few.
When starting my TCP server using Vertx, I have the following output :
[2018-06-04 12:15:45] [FINEST ] Net server listening on 0.0.0.0:/0:0:0:0:0:0:0:0:8600
[2018-06-04 12:15:45] [INFO ] Server is now listening on port : 8600
I was expected the second line, since I am telling Vertx to write it :
server.listen(res -> {
if (res.succeeded()) {
logger.info("Server is now listening on port : {0, number, #}", server.actualPort());
}
else {
logger.error("Server failed to bind");
}
});
The first line though, is written by Vertx itself. I am bit surprised, since I could not see anywhere in Vertx documentation that this would happen nor how to prevent it from doing so.
How can I make Vertx stop logging automatically?
Thanks in advance.
Well, the manual states that vert.x by default uses java.util.logging, often referred to by its nickname JUL. It's configurable so depending on your use case you should be able to tune the log output. Alternatively vert.x can be instructed to use an external logging framework, they each have their own advantages and disadvantages.
The documentation for JUL isn't really the most helpful prose ever written, fortunately there are plenty of third party sites covering that topic, like http://tutorials.jenkov.com/java-logging/index.html but a quick Google will point you to many others too.
Resuming:
you will need to write a logging.properties file that reflects the output you want to obtain, and where (in logfiles and/or on the console)
you will have to pass that file to your vert.x application via the system property java.util.logging.config.file
Limiting the info produced by certain application parts can be done by using the filtering capabilities present in JUL. So, for example, in your logging.properties you could put
java.util.logging.FileHandler.level=INFO
which will restrict logging that goes to the logfile to INFO or higher. That like for example would already do away with the vert.x log you see in your example. You can also restrict logging per package, group of packages or even individual classes. A nice writeup of these possibilities can be found here: java.util.logging: how to set level by logger package (or prefix)? . I think vert.x uses the prefix io.vertx
I've been playing around with Google Cloud Endpoints (Java) and I'm having trouble getting the APIs to update after I deploy to App Engine (using both Eclipse + Google Plugin and Android Studio).
I created an Endpoint based on a class called Process (annotated with JPA). It sits in my package (let's say: com.example). The first time I deployed it I had accidentally imported the wrong class (java.lang.Process instead of my com.example.Process). So I got this error when I tested one of the methods in the API explorer:
com.google.api.server.spi.SystemService invokeServiceMethod: cause={0}
javax.persistence.PersistenceException: No meta data for java.lang.Process. Perhaps you need to run the enhancer on this class?
I have then corrected the import, re-generated the client libraries and re-deployed the app to App Engine, but I keep getting the same error. As if App Engine still thinks I'm using java.lang.Process instead of my Process class.
I also made other changes. Like class member variable types and method names and re-deployed. But App Engine doesn't seem to notice these changes.
I read about how the API explorer "violently caches" so I tried clearing the cache, opened in another browser and even on another PC. Still nothing.
Also, I opened the discovery files for my api located in https://.appspot.com/_ah/api/discovery/v1/apis//v1/rest
I noticed that the variables types I had changed are still listed as the old types.
I checked the logs for my deploys. They all look ok:
2013-07-06 18:59:59.960 /_ah/spi/BackendService.getApiConfigs 200 291ms 14kb
I 2013-07-06 18:59:59.706 com.google.api.server.spi.BackendService getApiConfigs: apiConfigDir=/base/data/home/apps/s~<my-app>/1.368601601499931812/WEB-INF
I 2013-07-06 18:59:59.707 com.google.api.server.spi.BackendService getApiConfigs: apiConfigFile=/base/data/home/apps/s~<my-app>/1.368601601499931812/WEB-INF/<my-api-name>-v1.api
I 2013-07-06 18:59:59.713 com.google.api.server.spi.BackendService getApiConfigs: apiConfigFile=/base/data/home/apps/s~<my-app>/1.368601601499931812/WEB-INF/messageEndpoint-v1
I 2013-07-06 18:59:59.740 com.google.api.server.spi.BackendService getApiConfigs: apiConfigFile=/base/data/home/apps/s~<my-app>/1.368601601499931812/WEB-INF/deviceinfoendpoint
and in Admin Logs:
2013-07-06 18:59:35 <me> Successfully updated API configuration version=1
2013-07-06 18:59:35 <me> Completed update of a new default version version=1.2013-07-06T21:59:30Z
2013-07-06 18:59:32 <me> Deployed a new version version=1.2013-07-06T21:59:30Z
Anyone has any idea?
Thanks in advance.
It doesn't seem like your .api files are regenerating properly. If you delete the .api files, do they regenerate upon loading either in dev or to the App Engine?
Common reasons why .api files are re-created with updated information (i.e., mistakes I made in the past):
Primitives and enums are not allowed. You must pass back a Bean.
API methods are not annotated
API methods are "private" instead of "public"
This basically has me at a loss, and has for almost a week. I'm working on a part of company architecture, trying to get REST all set up. There are two methods that are not in the javax.ws.rs package - SEARCH and PATCH. I've created the following interface in our project to implement SEARCH: (mostly a copy/paste from examples)
/** imports and such as appropriate **/
#Target({ElementType.METHOD})
#Retention(RetentionPolicy.RUNTIME)
#HttpMethod("SEARCH")
public #interface SEARCH {
}
The code using this works flawlessly if called against it directly. However, the web service that talks to the main service fails every time with 500 Invalid HTTP method: SEARCH. So, to be clear, there are two web-enabled services. The first that uses the above code works fine. The second, which is supposed to be nothing but a proxy to the first service fails.
The second service that is having the problem runs on jetty. The servlet that is doing the proxying is an extension of org.mortbay.servlet.ProxyServlet - the only overrides are on init and proxyHttpUrl to do a little bit of URL tweaking. I know that the second service doesn't pass the response into the first because I can shut down the first and the second still gives me that error back.
My question is, am I missing configuration pieces to enable "custom" (i.e. not in the javax.ws.rs package) http methods?
First off, that proxy servlet code is very old, from jetty-6 unless I am mistaken. We have released jetty-9 now, and the last three versions of jetty have come from eclipse so the ProxyServlet you ought to be using is the org.eclipse.jetty.servlets.ProxyServlet class.
Now, from jetty-7 on we added some customization to that proxy servlet so you could modify much more of the client exchange...and you might need to make use of that to get additional http methods working. It could be that the http-client only excepts standard http methods in which case we would have to fix that up for your use case (open a bug at bugs.eclipse.org under RT/Jetty if that is the case).
I want to configure a self-written JCA 1.6 inbound resource adapter (RA). My big problem is that the RA needs to get access to some (dynamic) configuration data living in the application that uses the RA.
Now I know that this is against the original idea of the whole JCA idea but unfortunately I cannot change this design as quickly as I'd like/have to.
The data I need to get to the RA is
the port it's supposed to listen on,
the license used for the whole application (the feature the RA supplies requires extra licensing)
additional configuration data stored in a db
I've come up with four ideas:
Use the asadmin create-resource-adapter-config. Due to the fact that glassfish doesn't seem to restart apps depending on the RA, we need to restart the application after this. While this attempt is suitable for the port, it won't fit for the other data.
Use administered objects to give my application a means to pass data in to the RA. This idea is mentioned here. I guess this does it, but the spec states in chapter 13.4.2.3 that
Note, administered objects are not used for setting up asynchronous message
deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all
the necessary activation information needed for asynchronous message delivery
setup.
But I cannot get any dynamic data to the ActivationSpec object (neither through a DeploymentDescriptor nor through annotations). Or did I miss something here? :-)
Use JDBC directly to access the data (also grabbed the idea from here). While this is presumably the best idea, it does not work for the mentioned licensing data as it is not stored in the db.
The last idea I had was to put a method in the MessageDrivenBean (through my interface) that is used to fetch data from within the RA. That method could be called from the RA and would supply the data. But: I just think that is quite abusive as it couples the RA to the app.
Dear community, what are your thoughts on this one? I'm afraid it's not so easy to find answers to these questions, so I'd be quite happy about opinions!
Thanks and cheers,
Julius
In the ra.xml there is the possibility to define config-properties. In Websphere these then show up as editable fields in a table of custom properties for the selected resource adapter. I'm working on a similar problem, I also need to pass hostname / port info to an RA. Unfortunately I haven't figured out how to read the contents of these fields from within the RA however.
The solution I finally came up with is to use the #ConfigProperty annotation. This means I use option one of my question above.
So my ResourceAdapter class looks like this:
public class Hl7ResourceAdapter implements ResourceAdapter {
#ConfigProperty
private Integer port = null;
// Rest from ResourceAdapter interface omitted here...
// Use port here to open socket...
}
The #ConfigProperty fields can now be set through either
a resource-adapter-config
the ra.xml deployment descriptor
Now in order to reconfigure these settings I use glassfish's REST interface to change these settings programmatically (one could also use the asadmin create-resource-adapter-config command). I circumvent the problem, that glassfish does not restart the application that uses the resource adapter by simply restarting it myself through REST. (To be precise: I disable the application and then reenable it to get around another bug in glassfish)
A few additional notes:
We deploy the resource adapter's .rar file into the .ear of the application using it.
We have a separate application outside glassfish (standalone) that calls the REST interface to do such things as restart the resource adapter application etc. It is obvious that an application cannot restart itself properly.
Hope this helps. kutuzof, will this get you any further?