I have now tried everything that I can think of and the problem
persists. I must have done close to a hundred runs at this point.
* I have tried different GlassFish versions. While newer versions
seem to make thing worse, older versions still intermittently
cause this issue.
* I have tried different Arquillian timeout and retry settings.
None seem to have an effect.
* I have tried different JDKs, versions, and JDK locations
without spaces. This does not seem to be the issue.
I am happy to try further suggestions. If there are none, I am
going to document this as a known issue for the Cargo Tracker
project. If I receive too may user complaints, I'll remove
GlassFish support from Cargo Tracker for now.
On 3/25/2025 9:38 AM, Reza Rahman
wrote:
This is simply bizarre. I am out of time this morning but I
will validate this observation in the evening.
This entire problem started with an attempted upgrade to 7.0.22
(looks like by someone who did not test on Windows). It's worse
with 7.0.23. It seems to not be a problem in 7.0.21.
I would still be very keen on moving to
GlassFish Embedded in a way that's proper for an Eclipse
Foundation project if that's possible instead. This problem
can be someone else's headache to solve.
I did notice that if GlassFish was
not shut down completely, I get this:
Waiting finished after 60,001 ms.
No response from the Domain Administration Server
(domain1) after 60 seconds.
The command is either taking too long to complete or the
server has failed.
Please see the server log files for command status.
Please start with the --verbose option in order to see
early messages. No response from the Domain Administration
Server (domain1) after 60 seconds.
The command is either taking too long to complete or the
server has failed.
Please see the server log files for command status.
Please start with the --verbose option in order to see
early messages.
I'll try to pin down under what exact
conditions this happens. It's not easy to reproduce. This
is easier to reproduce manually:
There is a process already using the
admin port 4,848 -- it probably is another instance of a
GlassFish server.
On 3/24/2025 10:44 AM, Reza Rahman
wrote:
This is what I did:
C:\GitHub\cargotracker> cd
"C:\Program Files\Eclipse
Adoptium\jdk-17.0.8.101-hotspot\bin\"
When I try with the OmniFish
plugin, I get a slightly different error with the
same overall symptoms. The stack trace is
attached.
On 3/23/2025 6:36 PM, Reza
Rahman wrote:
Thanks very
much for taking a look. I can try the OmniFish
plugin as a test.
However, I
cannot use it in the project in relation to
GlassFish. I must use something in the GlassFish
or Arquillian domain instead. I’ve already
checked with the EMO on this. My hope would be
that either the Arquillian plugin is properly
maintained or a plugin is created within the
GlassFish project. Alternatively, I would not
mind adding support for an OmniFish branded
runtime. That’s also something that the EMO has
suggested.
I haven't tried
anything yet, but from a cursory glance at
master the first thing that stands out is that
for GlassFish an alpha version of the
unmaintained JBoss Arquillian connector is used,
that was only suited for GlassFish 6:
The Cargo Tracker project (https://github.com/eclipse-ee4j/cargotracker)
has tried to support GlassFish but once again
I am running into seeming
stability issues. While running tests with
Arquillian, the attached
issue now suddenly crops up. I have absolutely
no idea what is going on.
Honestly, this sort of thing never happens
with Payara or Liberty, which
are the two other runtimes Cargo Tracker
supports.
Is there someone here that can help? Otherwise
I will remove GlassFish
support from Cargo Tracker for now.