Столкнулся с тем, что апплет на одной странце почему-то запускается два раза вместо одного.
Запуски происходят подряд, с минимальным интервалом, оба экземпляра пытаются обратиться к одним и тем же ресурсам, что влечет за собой ошибки.
В странице апплет встроен только один раз. Ошибка носит плавающий характер.
На англоязычных форумах тоже читал описание такого глюка, но внятного решения не увидел. Приходится придумывать обходной путь

В связи с этим, вопрос — как можно программно ограничить количество экземпляров апплета?
Пока в голову приходит мысли о lock-файле или какой-нибудь встроенной в java реализации Singleton (слышал такое применительно к родному java logging). Общая идея — хранить вне апплета флаг, проверяя и устанавливая который можно будет продолжать работу(для первого экземпляра) или завершать(для последующих).
Посоветуйте, как лучше это сделать?

p.s. Просьба не предлагать перейти с апплета на JWS

Здравствуйте, Debussy, Вы писали:

D>p.s. Просьба не предлагать перейти с апплета на JWS
Апплен и JWS уже практически одно и то же. Не пробовал выяснить почему получаются две экземпяра? Посмотреть, например, стек в методе init, или в дефолтном конструкторе класса?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Debussy, Вы писали:

D>>p.s. Просьба не предлагать перейти с апплета на JWS
B>Апплен и JWS уже практически одно и то же.
Согласен, но есть небольшое, но очень критичное для меня различие — JWS не дает возможности работать с файловой системой пользователя. Это единственное, ради чего тут используется апплет.

B>Не пробовал выяснить почему получаются две экземпяра? Посмотреть, например, стек в методе init, или в дефолтном конструкторе класса?
А как это посмотреть? Проблема в том, что у меня ошибка пока не появляется, а у клиентов она появляется случайным образом.

Здравствуйте, Debussy, Вы писали:

D>Согласен, но есть небольшое, но очень критичное для меня различие — JWS не дает возможности работать с файловой системой пользователя. Это единственное, ради чего тут используется апплет.
Озадачен. В чем принципиальная разница??? Или у вас просто не получилось?

B>>Не пробовал выяснить почему получаются две экземпяра? Посмотреть, например, стек в методе init, или в дефолтном конструкторе класса?
D>А как это посмотреть? Проблема в том, что у меня ошибка пока не появляется, а у клиентов она появляется случайным образом.
Может у вас оккупируеются какие-то ресурсы типа потоков и потом не уничтожаются в методе destory? И второй экземпляр остается жить после перезегрузки страницы.
Какая ошибка происходит? Вероятно она происходит на каком-то критическом ресурсе? Может его и стоит использовать для разруливания конкурентного доступа?

Здравствуйте, Debussy, Вы писали:

D>Здравствуйте, Blazkowicz, Вы писали:

B>>Здравствуйте, Debussy, Вы писали:

D>>>p.s. Просьба не предлагать перейти с апплета на JWS
B>>Апплен и JWS уже практически одно и то же.
D>Согласен, но есть небольшое, но очень критичное для меня различие — JWS не дает возможности работать с файловой системой пользователя. Это единственное, ради чего тут используется апплет.

Это как это не дает? Это как раз в аплете шаги в стороны запрещены пока на клиенте секьюрити не настроишь. А Java Web Start как раз с этим ве в порядке. Лично я спокаой пишу клиенту в файлы все что угодно.

Здравствуйте, Nicht, Вы писали:

N>Здравствуйте, Debussy, Вы писали:

D>>Здравствуйте, Blazkowicz, Вы писали:

B>>>Здравствуйте, Debussy, Вы писали:

D>>>>p.s. Просьба не предлагать перейти с апплета на JWS
B>>>Апплен и JWS уже практически одно и то же.
D>>Согласен, но есть небольшое, но очень критичное для меня различие — JWS не дает возможности работать с файловой системой пользователя. Это единственное, ради чего тут используется апплет.

N>Это как это не дает? Это как раз в аплете шаги в стороны запрещены пока на клиенте секьюрити не настроишь. А Java Web Start как раз с этим ве в порядке. Лично я спокаой пишу клиенту в файлы все что угодно.

Странно, вроде я даже в спеках вычитывал, что нельзя, но после ваших слов попробую.
Да, второе условие — нужно взаимодействовать с веб-страницей.
Вкратце, это нужно для того, чтобы перед отправкой POST-формы на сервер подписывать ее ключом пользователя (тут и происходит обращение к файлам).

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Debussy, Вы писали:

D>>Согласен, но есть небольшое, но очень критичное для меня различие — JWS не дает возможности работать с файловой системой пользователя. Это единственное, ради чего тут используется апплет.
B>Озадачен. В чем принципиальная разница??? Или у вас просто не получилось?

Следующее по треду сообщение озадачило и меня. В любом случае, система давно написана и работает и пока нет возможности ее переписывать. Стоит попытаться решить эту проблему

B>>>Не пробовал выяснить почему получаются две экземпяра? Посмотреть, например, стек в методе init, или в дефолтном конструкторе класса?
D>>А как это посмотреть? Проблема в том, что у меня ошибка пока не появляется, а у клиентов она появляется случайным образом.
B>Может у вас оккупируеются какие-то ресурсы типа потоков и потом не уничтожаются в методе destory? И второй экземпляр остается жить после перезегрузки страницы.

Да, с апплетами это иногда бывает, но критическая секция у меня длится недолго, да еще и идет в конструкторе. Так что подобной проблемы никогда не возникало.
Здесь же апплет запускается дважды иногда и на только стартовавшей jvm, на впервые загруженной странице. И оба запуска практически одновременно, потому и до критической секции доходят вместе.


B>Какая ошибка происходит? Вероятно она происходит на каком-то критическом ресурсе? Может его и стоит использовать для разруливания конкурентного доступа?

Ошибка ввода-вывода, IO. Да, именно что на критическом ресурсе, идея хорошая, но использовать ресурс таким образом не получится — особенности его API (не можем узнать, занят ли ресурс или отсутсвует, а на отсуствие уже навешана логика)

Не смогли бы вы подробнее написать про стек, как его посмотреть?

Здравствуйте, Debussy, Вы писали:

D>Не смогли бы вы подробнее написать про стек, как его посмотреть?
Thread.dumpStackTrace()
Надо ещё по процессам посмотреть сколько запущено JVM, потому как в последних версиях апплет можно запускать в разных JVM.
Надо так же дампить имя класслоадера. Может все же дело в плагине и он ошибочно и апплет загружен 2 раза, и разнице в стеке исполнения не будет видно.

Здравствуйте, Debussy, Вы писали:

D>Да, с апплетами это иногда бывает, но критическая секция у меня длится недолго, да еще и идет в конструкторе. Так что подобной проблемы никогда не возникало.
Вот это и есть ошибка. Нельзя привязыватся к конструктору апплета. Плагин имеет право его инстанциировать сколько ему надо раз. Ведь есть специальный метод init

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Debussy, Вы писали:

D>>Да, с апплетами это иногда бывает, но критическая секция у меня длится недолго, да еще и идет в конструкторе. Так что подобной проблемы никогда не возникало.
B>Вот это и есть ошибка. Нельзя привязыватся к конструктору апплета. Плагин имеет право его инстанциировать сколько ему надо раз. Ведь есть специальный метод init

Простите, не было кода под рукой — и я ошибся, конечно же используется метод init

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Debussy, Вы писали:

D>>Не смогли бы вы подробнее написать про стек, как его посмотреть?
B>Thread.dumpStackTrace()
B>Надо ещё по процессам посмотреть сколько запущено JVM, потому как в последних версиях апплет можно запускать в разных JVM.
B>Надо так же дампить имя класслоадера. Может все же дело в плагине и он ошибочно и апплет загружен 2 раза, и разнице в стеке исполнения не будет видно.


Консоль и класслоадер буду дампить, спасибо. Ошибка плавающая, у меня не проявляется, а встречается случайным образом у клиентов, так что дамп будет полезен.
Поскольку установлен флажок "всегда показывать консоль", думаю, можно судить о количестве запущенных jvm по консолям. Консоль одна, и именно в ней видно одновременно выполнение.