-XX:NativeMemoryTracking=detail
jps
ps -p <PID> -o pcpu,rss,size,vsize
import java.text.*; | |
import java.io.*; | |
import java.util.*; | |
String filename = "oprosnik_" + vars.get("fileNum") + ".csv"; | |
ArrayList strList = new ArrayList(); | |
try { | |
File file = new File(filename); |
import java.util.Random; | |
/** | |
* A credit card number generator. | |
* | |
* @author Josef Galea | |
*/ | |
public class CreditCardNumberGenerator { | |
private Random random = new Random(System.currentTimeMillis()); |
I'm afraid the paths you are storing in MongoDB won't be very useful, since they are simply the default toString() representation of the referenced collection item. In order to use this path to access the property via java-object-diff, you'd need to be able to deserialize it to an actual instance of an object that has the same identity (equals == true
) as the one you want to reference.
There are ways to do that, like writing a custom serializer for the PropertyPath to serialize a deserializable version of the reference item, but that leads to pretty verbose JSON and is rather fragile.
I personally don't recommend storing the diff in a database, but rather compare two document versions on demand. Depending on your scenario that may or may not cause performance issues. If it does, there are usually ways to cache the information you actually need, without storing the entire diff in the database.
I once had the same problem when I tried to generate a Github-like activity stream. I first approached it by stor
@Component | |
@Conditional(MyComponent.EnabledCondition.class) | |
public class MyComponent { | |
protected static class EnabledCondition implements Condition { | |
private static final String ENABLED_PROPERTY = "mycomponent.enabled"; | |
@Override | |
public boolean matches(final ConditionContext context, final AnnotatedTypeMetadata metadata) { | |
final Environment environment = context.getEnvironment(); | |
return environment != null && Boolean.valueOf(environment.getProperty(ENABLED_PROPERTY)); | |
} |
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
import java.io.*; | |
import java.nio.*; | |
import java.nio.channels.*; | |
/** | |
* Compares the performance of streaming data to disk vs using memory mapped files. | |
*. | |
public class MappedIO { | |
private static int numOfInts = 4000000; |
The logstash agent is 3 parts: inputs -> filters -> outputs.
Each '->' is an internal messaging system. It is implemented with a 'SizedQueue' in Ruby. SizedQueue allows a bounded maximum of items in the queue such that any writes to the queue will block if the queue is full at maximum capacity.
Logstash sets the queue size to 20. This means only 20 events can be pending into the next phase - this helps reduce any data loss and in general avoids logstash trying to act as a data storage system. These internal queues are not for storing messages long-term.
In reverse, here's what happens with a queue fills.
@ControllerAdvice | |
public class CustomResponseEntityExceptionHandler extends ResponseEntityExceptionHandler { | |
@Override | |
protected ResponseEntity<Object> handleMethodArgumentNotValid(MethodArgumentNotValidException ex, HttpHeaders headers, HttpStatus status, WebRequest request) { | |
List<FieldError> fieldErrors = ex.getBindingResult().getFieldErrors(); | |
List<ObjectError> globalErrors = ex.getBindingResult().getGlobalErrors(); | |
List<String> errors = new ArrayList<>(fieldErrors.size() + globalErrors.size()); | |
String error; | |
for (FieldError fieldError : fieldErrors) { |
Mostly about the java.time package, about time and date format issue. | |
Nothing Special, just for reference. |