Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#104 closed defect (fixed)

Plugin: start/stop for seedless

Reported by: anonymous Owned by: sponge
Priority: minor Milestone: 0.8.2
Component: apps/console Version: 0.8.1
Keywords: Cc:
Parent Tickets: Sensitive: no

Description

Running i2p on Windows xp.

At the bottom of the clients page where it shows the plugins installed:

it shows neodatis with a stop button (that is fine, because it has started).

BUT

it shows seedless with a start button (and no stop button) even though it has started.

Subtickets

Change History (10)

comment:1 Changed 9 years ago by zzz

Component: api/dataapps/console
Owner: set to sponge
Priority: majorminor
Status: newassigned
Summary: Plugin: start/stopPlugin: start/stop for seedless

May be a console bug or a plugin interface bug or maybe it's something to do with the way the plugin is using threads, not sure

comment:2 Changed 9 years ago by sponge

Status: assignedaccepted
Version: 0.8.1

comment:3 Changed 9 years ago by sponge

Verified, happens on Linux 64bit and 32bit. Will see what I can do.

comment:4 Changed 9 years ago by sponge

Owner: changed from sponge to zzz
Status: acceptedassigned

Apparently the plugin API expects that if you execute something, if it exits, that it has stopped.
This isn't true in the case of seedless, where what is executed only does a class inclusion. The neodatis plugin executes 2 methods… The class includer, then the neodatis server. Since the server stays running, the stop button appears. This is a bug in plugins, it should check if webapp is alive too.

Basically a plugin is running if some thread is working OR it has an active webapp.
For now I could put in an update that fixes this bad behavior.

Since this is a plugin logic defect, I reassign it to zzz.

@zzz: If you wish for me to fix this instead, simply reassign it to me, as I realize you are overloaded with bugs.

comment:5 Changed 9 years ago by zzz

Owner: changed from zzz to sponge

I just looked at PluginStarter?.isPluginRunning() which is called by ConfigClientsHelper?.getForm3(). It _does_ check for either a client thread or a webapp, so your guess isn't 100% correct, but you're on the right track.

Still not sure if it's a bug in the plugin code or somthing special about your plugin. Look at isPluginRunning().

This code was done by HH and it was a while ago… so I'm not overly familiar with it atm.

Reassigning back to you since you volunteered.

comment:6 Changed 9 years ago by sponge

return isClientThreadRunning(pluginName)
WebAppStarter?.isWebAppRunning(pluginName) isJobRunning;

Ok, so there is the or case, thus it may be in WebAppStarter?.isWebAppRunning(pluginName)… It's a bit interesting that the sidebar shows it properly, perhaps hints can be gleaned from there.

Working on it now, untangling the code… :-)

comment:8 Changed 9 years ago by sponge

I think we need to store a list of webapps. That would resolve the entire issue. The case here is war filename != plugin name. So I'll store a list of war files for each plugin context. That would allow multiple war files deployed, and avoid all sorts of other brokenness that can happen.

@zzz: If you think this is a wrong way to fix, please tell me. Thanks.

comment:9 Changed 9 years ago by sponge

Resolution: fixed
Status: assignedclosed

Patched, works with seedless and bote, so should work with everything.

comment:10 Changed 9 years ago by zzz

Milestone: 0.8.2
Note: See TracTickets for help on using tickets.