Motivation

Revise official documents to make them easy to understand and use

Modifications

• Correction of incorrect document
• Add hyperlink jump for file
• Correct inappropriate punctuation
• Correction output

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

• Dependencies (does it add or upgrade a dependency): ( no)
• The public API: (no)
• The schema: ( no )
• The default values of configurations: ( no)
• The wire protocol: (no)
• The rest endpoints: (no)
• The admin cli options: (no)
• Anything that affects deployment: (no)

Why is this changed back?

Revision: 31fc14eeb7ca55e24fdf6fc01f506e5988a30c7d

Submitted crossbow builds: ursacomputing/crossbow @ actions-504

Task	Status
test-r-linux-valgrind

@github-actions crossbow submit test-r-linux-valgrind

https://issues.apache.org/jira/browse/ARROW-13129

https://issues.apache.org/jira/browse/ARROW-13128

Motivation

Java client fails with Java 16 while receiving a message. Error:

[org.apa.pul.cli.imp.ClientCnx] (pulsar-client-io-2-1) [localhost/127.0.0.1:6650] Got exception java.lang.NoClassDefFoundError: Could not initialize class io.airlift.compress.lz4.UnsafeUtil
	at io.airlift.compress.lz4.Lz4RawDecompressor.decompress(Lz4RawDecompressor.java:60)
	at org.apache.pulsar.common.compression.CompressionCodecLZ4.decode(CompressionCodecLZ4.java:91)
	at org.apache.pulsar.client.impl.ConsumerImpl.uncompressPayloadIfNeeded(ConsumerImpl.java:1507)
	at org.apache.pulsar.client.impl.ConsumerImpl.messageReceived(ConsumerImpl.java:1037)
	at org.apache.pulsar.client.impl.ClientCnx.handleMessage(ClientCnx.java:447)
	at org.apache.pulsar.common.protocol.PulsarDecoder.channelRead(PulsarDecoder.java:186)
...

Can be reproduced with the official example for Java Client from the docu while using JDK 16.

Modifications

Upgrade io.airlift.aircompressor to version 16. Locally I use pulsar-client-original, and exclude the aircompressor 16. Example:

<dependency>
  <groupId>org.apache.pulsar</groupId>
  <artifactId>pulsar-client-original</artifactId>
  <version>${pulsar.version}</version>
  <exclusions>
    <exclusion>
      <groupId>io.airlift</groupId>
      <artifactId>aircompressor</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<!-- https://mvnrepository.com/artifact/io.airlift/aircompressor -->
<dependency>
  <groupId>io.airlift</groupId>
  <artifactId>aircompressor</artifactId>
  <version>0.16</version>
</dependency>

• Dependencies yes upgrade

Got it! AFAIU only the fixed sized typed if-else kernels qualify for can_write_into_slices category then, isn't it?

Revision: a057f126683485806e0e090e1d7f0b12800125d2

Submitted crossbow builds: ursacomputing/crossbow @ actions-503

Task	Status
test-r-linux-valgrind

LGTM, I'll look into the valgrind error that looks like it's from these tests next week. Thank you for catching this so quickly!

@github-actions crossbow submit test-r-linux-valgrind

https://issues.apache.org/jira/browse/ARROW-13127

Might be fixed with #952

Okay, so this was a pretty deep problem to solve.

I noticed that the problem only occurred on velocity at deployment, ground hit velocity and optimum delay. After a bit of searching, I found that the simulation events of recovery device hit and ground hit in BasicSimulationEngine weren't getting triggered. To see what happens, I printed some log info about the simulation events when the problem arose and this was the output. The following shows in chronological order the different simulation events that occur after I have changed a parameter of a rocket component (event of altitude change not included, because there were a lot of them): Event - Launch Event - Motor ignition Event - Lift-off Event - Launch rod clearance Event - Motor burnout Event - Ejection charge Event - Apogee Event - Simulation end

For reference, this is the desired event log, from a normal simulation run: Event - Launch Event - Motor ignition Event - Lift-off Event - Launch rod clearance Event - Motor burnout Event - Ejection charge Event - Apogee Event - Simulation end Event - Recovery device deployment Event - Recovery device deployment Event - Ground hit Event - Simulation end

You can see that the simulation just ends after apogee. The culprit for this was the handleFlightEvent method in ApogeeEndListener. The ApogeeEndListener is instantiated in getExtraListeners in RocketPanel in the SimulationListener interface. This basically makes it so that when you change a parameter of the rocket and a simulation is auto run, when that simulation hits apogee, the next event of the simulation will be SIMULATION_END, as can be seen in ApogeeEndListener. This is not what we want, we want the simulation to stop after ground hit.

Therefor, I created a new listener, GroundHitListener, which will end the simulation after ground hit. This solves the issue.

I have to admit that I am not sure why the choice was made to stop the simulation after apogee in the first place, but I believe that ground hit should be the right way to end your simulation?

On top of that, I found a secondary problem. When you just changed a component value and change a value again, whilst the simulation is still calculating the first change (you can see it in the rocket preview window on the bottom left 'Calculating…'), then it also triggers a simulation end after apogee. This is a log of the events of first changing a component value and then doing it again during calculation. Note the 'simulation end' after apogee. using pre-existing simulation Event - Launch Event - Motor ignition Event - Lift-off Event - Launch rod clearance using pre-existing simulation Event - Launch Event - Motor ignition Event - Lift-off Event - Launch rod clearance Event - Motor burnout Event - Ejection charge Event - Apogee Event - Simulation end Event - Recovery device deployment Event - Recovery device deployment Event - Ground hit Event - Simulation end

I will leave this last problem for a different pull request however, since it is not closely related to the concerning current issue.

I also still have to fix the issue that the simulation status remains in the red (out-of-date) state, even when the simulation is updated; it goes to the green (up-to-date) state once I close the dialog of the component configuration.

Here is a jar for testing.

Fixes #927 (and possibly also #771 ?)

Documentation for EventPoller per #367

While updating the changelog I noticed that all the changes are listed under "Breaking changes." Perhaps you would like to separate out the breaking changes from the others? You could use 3 categories for breaking changes, deprecations, and the rest.

Sure, I'll happily make a PR for this. There's no rush; it is OSS after all.

As I am also so inclined, I totally understand the need to minimize API surface or else make what's exposed high-quality API. The EventPoller is still marked as experimental. Are you looking for more tests before you declare this a stable feature?

Revision: c81764c8e23c8ca00b0c538a6b3fc6c42f336b68

Submitted crossbow builds: ursacomputing/crossbow @ actions-502

Task	Status
test-r-linux-valgrind