Oracle WebLogic Server: এন্টারপ্রাইজ Middleware-এ দক্ষতা

Oracle WebLogic Server হলো সেই নীরব কর্মবীর যা অসংখ্য mission-critical Java EE অ্যাপ্লিকেশনের পেছনে চলে — ব্যাংকিং প্ল্যাটফর্ম, ERP সিস্টেম, টেলিকম বিলিং, বিমা দাবি, হেলথকেয়ার রেকর্ড। একাধিক ইন্ডাস্ট্রিতে version 10g থেকে 14c পর্যন্ত WebLogic পরিবেশ deploy ও পরিচালনার পর আমি বলতে পারি, যে WebLogic নীরবে গুনগুন করে চলে আর যেটি রাত ২টায় আপনাকে জাগিয়ে তোলে — এ দুইয়ের পার্থক্য প্রায় সবসময়ই install-এর সময় নেওয়া আর্কিটেকচার সিদ্ধান্তে নিহিত। এই বিস্তৃত গাইড WebLogic-কে ভিত্তি থেকে প্রোডাকশন দক্ষতা পর্যন্ত কভার করে।

১. Oracle WebLogic Server কী?

Oracle WebLogic Server হলো একটি এন্টারপ্রাইজ-গ্রেড Java EE (এখন Jakarta EE) অ্যাপ্লিকেশন সার্ভার যা Java অ্যাপ্লিকেশন host ও পরিচালনা করে। এটি servlet, JSP, EJB, JMS messaging, JDBC pooling, web service, REST API এবং জটিল transactional অ্যাপ্লিকেশনের জন্য runtime পরিবেশ দেয়। WebLogic হলো আপনার শেষ ব্যবহারকারী (ব্রাউজার, মোবাইল অ্যাপ) ও আপনার backend database (সাধারণত Oracle)-এর মধ্যেকার অ্যাপ্লিকেশন স্তর।

এটি ব্যাপকভাবে ব্যবহৃত হয়:

• Oracle E-Business Suite, Oracle Fusion Middleware, SOA Suite, BPM Suite
• ব্যাংকিং অ্যাপ (core banking, internet banking, payment gateway)
• টেলিকম OSS/BSS প্ল্যাটফর্ম
• বিমা দাবি ও পলিসি ব্যবস্থাপনা সিস্টেম
• নিয়ন্ত্রিত ইন্ডাস্ট্রিতে কাস্টম Java EE অ্যাপ্লিকেশন

১.১ ২০২৬ সালেও এন্টারপ্রাইজগুলো কেন WebLogic চালায়?

কারণ তাদের সবচেয়ে গুরুত্বপূর্ণ অ্যাপ্লিকেশনগুলোর আর কোথাও যাওয়ার জায়গা নেই। Oracle Forms ও Reports — যা এখনও হাজারো ম্যানুফ্যাকচারার, হাসপাতাল আর ট্রেডিং হাউসের দৈনন্দিন কার্যক্রম চালায় — কেবল WebLogic-এই certified। E-Business Suite এর সঙ্গেই আসে। SOA Suite-এর এটি লাগবেই। WebLogic উপড়ে ফেলা মানে তার ওপরের অ্যাপ্লিকেশনটাই নতুন করে লেখা, আর চালু একটা ERP শখ করে কেউ নতুন করে লেখে না।

দ্বিতীয়, অপেক্ষাকৃত নীরব একটি কারণও আছে: এন্টারপ্রাইজ ফিচারগুলো সত্যিই কাজ করে। session-replicated clustering, distributed XA transaction, RAC node ব্যর্থতা সম্পর্কে Active GridLink-এর সচেতনতা, restart-এও টিকে থাকা একটি messaging সিস্টেম — এগুলো শক্তপোক্ত করতে Oracle-এর দুই দশক লেগেছে। কোনো ব্যাংক যখন আমাকে একটি core সিস্টেমের জন্য middleware ডিজাইন করতে বলে, "বিরক্তিকর কিন্তু প্রমাণিত" প্রতিবারই "আধুনিক ও রোমাঞ্চকর"-কে হারায়। এই দর্শন নিয়ে আরও বিস্তৃতভাবে লিখেছি আমার আইটি অবকাঠামো ডিজাইন গাইডে।

ক্যারিয়ারের জন্য এর ব্যবহারিক ফল: WebLogic আর প্রায় কেউই শিখছে না, অথচ installed base-টির আরও অন্তত এক দশক যত্ন দরকার। দুর্লভ দক্ষতা + দীর্ঘস্থায়ী চাহিদা — দাঁড়ানোর জন্য চমৎকার জায়গা; একই যুক্তি বর্ণনা করেছি আমার Oracle DBA ক্যারিয়ার গাইডে।

২. প্রোডাকশনে WebLogic সংস্করণ (২০২৬)

• WebLogic 12.2.1.4 — এখনও ব্যাপকভাবে deploy করা। Premier support বর্ধিত।
• WebLogic 14.1.1 — Java SE 8 ও 11, Java EE 8 সমর্থন
• WebLogic 14.1.2 — Java SE 17 ও 21, Jakarta EE 10 — নতুন deployment-এর জন্য বর্তমানে পছন্দসই

৩. WebLogic আর্কিটেকচার: মূল উপাদান

WebLogic-এর পরিভাষা নবাগতদের ভয় দেখায়, কিন্তু একে একটি ছোট সংগঠন হিসেবে দেখলে মডেলটি সরল। domain হলো কোম্পানি। AdminServer হলো প্রধান কার্যালয় — কনফিগারেশন রাখে ও নির্দেশ দেয়, কিন্তু কোনো প্রোডাকশন কাজ করে না। managed server-গুলো হলো কারখানা, যেখানে অ্যাপ্লিকেশন আসলে চলে। machine হলো ভৌত ঠিকানা, আর Node Manager হলো সাইটের কেয়ারটেকার — রাত ৩টায় কোনো কারখানা পুড়ে গেলে কাউকে না জাগিয়েই সেটি restart করতে পারে।

এই ছবিটা মনে রাখুন — WebLogic-এর প্রতিটি স্ক্রিন, log file আর WLST command জায়গামতো বসে যাবে।

৩.১ Domain

একটি WebLogic Domain হলো logical ব্যবস্থাপনা সীমানা — একটি একক প্রশাসনিক একক। একটি domain-এর ভেতরে আপনার থাকে:

• একটি Administration Server
• শূন্য বা একাধিক Managed Server
• ঐচ্ছিক Cluster যা managed server-গুলোকে দলবদ্ধ করে
• কনফিগারেশন: data source, JMS, security realm, অ্যাপ্লিকেশন

৩.২ Administration Server (AdminServer)

কেন্দ্রীয় নিয়ন্ত্রণ তল। WebLogic Console (port 7001-এ web UI), WLST (scripting) host করে এবং কনফিগারেশন পরিচালনা করে। কখনও AdminServer-এ প্রোডাকশন অ্যাপ্লিকেশন deploy করবেন না — এটি হালকা, নিরাপদ এবং কেবল প্রশাসনের জন্য নিবেদিত থাকা উচিত।

৩.৩ Managed Server

যেখানে আপনার অ্যাপ্লিকেশন আসলে চলে। প্রতিটি managed server একটি আলাদা JVM process যা নিজের port-এ শোনে। প্রোডাকশন domain-এ সাধারণত একাধিক managed server থাকে, প্রায়ই cluster-এ।

৩.৪ Node Manager

OS-স্তরের daemon (প্রতি physical/virtual সার্ভারে একটি) যা managed server শুরু, বন্ধ, restart ও মনিটর করে। HA-এর জন্য গুরুত্বপূর্ণ — একটি managed server মারা গেলে Node Manager স্বয়ংক্রিয়ভাবে তা restart করতে পারে। দুই ধরন:

• Plain Node Manager (সুপারিশকৃত): SSL credential দিয়ে authenticate করে
• Domain-Scoped Node Manager: প্রতি-domain কনফিগারেশন

৩.৫ Cluster

একগুচ্ছ managed server (এক বা একাধিক machine জুড়ে) যা একসঙ্গে কাজ করে দেয়:

• Load balancing — আগত request cluster সদস্যদের মধ্যে বণ্টন
• Failover — session replicate করা; একটি সদস্য মারা গেলে অন্যটি তুলে নেয়
• Scalability — বেশি লোড সামলাতে আরও সদস্য যোগ করা

৪. স্ট্যান্ডার্ড WebLogic Topology

একটি সাধারণ প্রোডাকশন deployment:

• ২টি physical সার্ভার (বা availability zone জুড়ে ২টি VM)
• machine 1-এ (বা pillar host) ১টি AdminServer
• প্রতি machine-এ ২টি Managed Server (মোট ৪টি), সবই এক cluster-এ
• প্রতিটি machine-এ Node Manager
• সামনে ট্রাফিক route করা Load Balancer / OHS (Oracle HTTP Server)
• অ্যাপ্লিকেশন ডেটার জন্য পেছনে Oracle Database

সামনের OHS বা Apache স্তরটি ঐচ্ছিক সাজসজ্জা নয়। এটি SSL terminate করে, আপনার managed-server port-গুলোকে ইন্টারনেট থেকে আড়াল করে, এবং — WebLogic proxy plug-in-এর মাধ্যমে — cluster member তালিকা জানে বলে মৃত একটি server-কে সেকেন্ডের মধ্যে এড়িয়ে route করে। আমার চালানো প্রতিটি Forms/Reports পরিবেশের সামনে OHS আছে; যে এক ক্লায়েন্ট managed server সরাসরি expose করতে জেদ ধরেছিল, প্রথম port scan-এর সময়ই কারণটা টের পেয়েছিল।

৫. একটি WebLogic Domain তৈরি করা

Configuration Wizard বা WLST ব্যবহার করুন। WLST দিয়ে দ্রুত উদাহরণ:

# Run from $MW_HOME/oracle_common/common/bin/wlst.sh
readTemplate('/u01/app/oracle/wls14/wlserver/common/templates/wls/wls.jar')
cd('/Servers/AdminServer')
set('ListenAddress', 'adminhost.company.com')
set('ListenPort', 7001)
cd('/Security/base_domain/User/weblogic')
cmo.setPassword('Welcome1#')
setOption('OverwriteDomain', 'true')
writeDomain('/u01/app/oracle/wls14/user_projects/domains/prod_domain')
closeTemplate()
exit()

৬. JDBC Data Source — ডেটাবেজের জীবনরেখা

WebLogic পারফরম্যান্স সমস্যার ৮০% জন্ম নেয় JDBC connection pool-এ। সেরা চর্চা:

৬.১ Standalone DB-এর জন্য Generic Data Source, RAC-এর জন্য GridLink

Oracle RAC backend-এর জন্য Active GridLink Data Source অপরিহার্য — এরা Oracle Notification Service (ONS) বোঝে, FAN event সামলায় এবং RAC লোড অনুযায়ী connection route করে। RAC-এর জন্য আর multi-pool data source ব্যবহার করবেন না।

৬.২ Connection Pool সাইজিং

• Initial Capacity: 5-10 (0 এড়িয়ে চলুন — প্রথম request connection খরচ বহন করে)
• Maximum Capacity: অ্যাপের চাহিদা অনুযায়ী, সাধারণত প্রতি managed server-এ 50-200
• Statement Cache Size: প্রতি connection-এ 30-50 cached prepared statement

৬.৩ গুরুত্বপূর্ণ সেটিং

• Test Connections On Reserve: প্রোডাকশনের জন্য ON
• Test Frequency: 60 সেকেন্ড (idle connection test)
• Inactive Connection Timeout: 60 সেকেন্ড
• Connection Reserve Timeout: 10 সেকেন্ড
• Test Table Name: SQL ISVALID (Oracle) বা সরল SELECT 1 FROM DUAL

৬.৪ যে Datasource Leak প্রোডাকশনে বারবার কামড়ায়

ক্লাসিক ব্যর্থতাটা দেখতে এমন: অ্যাপ্লিকেশন দিনের পর দিন ঠিকঠাক চলে, তারপর হঠাৎ request-গুলো PoolLimitSQLException: weblogic.common.resourcepool.ResourceLimitException দিয়ে timeout হতে শুরু করে। pool-এ Active Connections Current ঠিক Maximum Capacity-তে আটকে থাকে। server restart করলে সব আবার চলে — কয়েক দিনের জন্য। এই চক্রটাই connection leak-এর আঙুলের ছাপ।

কারণটা প্রায় সবসময়ই এমন অ্যাপ্লিকেশন কোড যা একটি connection ধার নেয় কিন্তু ফেরত দেয় না — এমন একটি code path যা close()-এর আগেই exception ছোড়ে, সাধারণত এমন এক error handler-এ যা কেউ কখনও টেস্ট করেনি। pool ধীরে ধীরে শুকিয়ে যায়, শেষে কিছুই থাকে না। WebLogic এটা প্রমাণ করার টুল দেয়:

• Inactive Connection Timeout = 300 — অ্যাপ্লিকেশন ৫ মিনিট idle ধরে রাখা connection-গুলো pool জোর করে ফিরিয়ে নেয়। এটি আপনার safety net, সমাধান নয়।
• Profile Connection Leak (datasource-এর Diagnostics ট্যাব) — leak হওয়া প্রতিটি connection যে কোড reserve করেছিল, তার সম্পূর্ণ Java stack trace WebLogic রেকর্ড করে। দায়ী class ও line number datasource profile log-এ ভেসে ওঠে; সেটা ডেভেলপারদের হাতে দিন — তর্ক শেষ।
• প্রতি সপ্তাহে Active Connections High Count নজরে রাখুন। যে সংখ্যা কেবলই বাড়ে, সেটি চলমান একটি leak — ব্যবহারকারীরা টের পাওয়ার আগেই।

এটা আমার চেকলিস্টে রাখি কারণ middleware স্তরে leak হওয়া একটি pool ব্যবহারকারীর দিক থেকে হুবহু ডেটাবেজ সমস্যার মতো দেখায় — অ্যাপ "ডেটাবেজে পৌঁছাতে পারছে না" — এবং আমি দেখেছি টিমগুলো এর পেছনে ছুটে মাঝরাতে সম্পূর্ণ সুস্থ ডেটাবেজ restart করছে। এই ভুল-নির্ণয়ের ধরনটাই আমার রাত ৩টার ডেটাবেজ ব্যর্থতা লেখার অর্ধেক।

৭. অ্যাপ্লিকেশন Deploy করা

তিনটি ফরম্যাট:

• WAR — Web Application Archive (servlet, JSP)
• EAR — Enterprise Application Archive (web + EJB module)
• Exploded directory — ডেভেলপমেন্টের জন্য উপযোগী

Console, WLST বা script-এর মাধ্যমে deploy করুন:

connect('weblogic','password','t3://adminhost:7001')
deploy(appName='myapp',
       path='/deploy/myapp.ear',
       targets='Cluster_Prod',
       upload='true',
       stageMode='stage')

৭.১ Staged বনাম Nostage: কোন Deployment Mode ব্যবহার করবেন?

cluster-এর জন্য stage mode আর shared storage সহ single-server domain-এর জন্য nostage ব্যবহার করুন। stage mode-এ AdminServer archive-টি প্রতিটি managed server-এর local staging ডিরেক্টরিতে কপি করে, ফলে প্রতিটি cluster সদস্যের নিজস্ব কপি থাকে এবং মূল file server বন্ধ থাকলেও restart করতে পারে। nostage সব server-কে একটিই shared path দেখায় — পরিচালনার জন্য এক কপি, কিন্তু একটিমাত্র point of failure।

যে ফাঁদটা বারবার দেখি: কেউ admin host-এর এমন এক path থেকে nostage deploy করে, যা অন্য machine-এর managed server-গুলো পড়তেই পারে না। deployment সফল হয়, আর পরের managed-server restart-এই অ্যাপটি মরে যায়। cluster-এর জন্য stage mode নিন, কপি করার কাজ WebLogic-কে করতে দিন।

৭.২ Zero Downtime-এর জন্য Side-by-Side Versioning

Production redeployment — zero-downtime অ্যাপ্লিকেশন আপডেটের জন্য side-by-side versioning ব্যবহার করুন। MANIFEST.MF-এ Weblogic-Application-Version সেট করুন (বা WLST-এ appversion পাস করুন), আর WebLogic পুরোনো ও নতুন version একসঙ্গে চালায়: বিদ্যমান session-গুলো পুরোনো version-এ শেষ হয়, নতুন request নতুনটায় পড়ে, এবং শেষ session ফুরালে পুরোনো version নিজেই অবসরে যায়। ব্যবহারকারীরা কখনও error page দেখে না। আগে non-prod-এ পরীক্ষা করুন — static state-এর অপব্যবহার করা অ্যাপ দুটি live version-এ গোলমাল করতে পারে।

৮. JMS ও Messaging

WebLogic JMS একটি সম্পূর্ণ-বৈশিষ্ট্যযুক্ত messaging সিস্টেম। উপাদান:

• একটি managed server-এ targeted JMS Server
• Persistent Store — JDBC store (RAC-safe) বা file store
• Destination — Queue (point-to-point) বা Topic (publish-subscribe)
• দূরবর্তী JMS server-এ store-and-forward-এর জন্য SAF Agent
• cluster-wide messaging-এর জন্য Distributed Destination

৯. Performance Tuning — আসল নব

৯.১ JVM Tuning — এবং যে 1 GB Heap বছরের পর বছর একটি Cluster-কে তাড়া করেছিল

আগে একটি যুদ্ধের গল্প, কারণ এতে পুরো শৃঙ্খলাটাই ধরা পড়ে। আমি এমন এক Forms/Reports estate উত্তরাধিকারে পেয়েছিলাম — ৬-instance এক WebLogic cluster-এ — যা বছরের পর বছর "একটু ধীর" ছিল; ব্যবহারকারীরা মেনেই নিয়েছিল যে স্ক্রিন ঘণ্টায় কয়েকবার কয়েক সেকেন্ডের জন্য জমে যাবে। সবাই ডেটাবেজকে দোষ দিত। AWR রিপোর্ট ছিল পরিষ্কার।

আসল গল্পটা বলল GC log: প্রতিটি managed server চলছিল installer-ডিফল্ট 1 GB heap-এ, আর স্বাভাবিক দিনের session লোডে প্রতিটি JVM জীবন কাটাচ্ছিল পিঠাপিঠি full GC চক্রে — জমে যাওয়াগুলো ছিল garbage-collection pause, ডেটাবেজ wait নয়। machine-গুলোয় প্রচুর ফাঁকা RAM ছিল; ডিফল্টটা কেউ কখনও ফিরে দেখেনি।

সমাধানটা প্রায় লজ্জাজনক রকমের সহজ: ছয়টি instance-এই -Xms/-Xmx 1 GB থেকে 4 GB করা, একবারে একটি server করে roll করে যাতে কোনো session না পড়ে। full GC-র হার প্রতি কয়েক মিনিটে একবার থেকে নেমে এল দিনে হাতে গোনা কয়েকবারে। বছরের পর বছর টিকিটের পর — "ধীর ERP"-র অভিযোগ সেই সপ্তাহেই থেমে গেল। মোট খরচ: একটি change window আর 18 GB RAM, যা এমনিতেই অলস বসে ছিল।

শিক্ষাটা "সবসময় 4 GB ব্যবহার করুন" নয় — শিক্ষাটা হলো ডিফল্ট heap একটি placeholder, সিদ্ধান্ত নয়, এবং middleware-এর মন্থরতা স্বীকারোক্তি দেয় GC log-এই। প্রমাণ থেকে size ঠিক করুন:

# Production JVM args for managed server (16GB heap)
-Xms16g -Xmx16g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:+ParallelRefProcEnabled
-XX:+DisableExplicitGC
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/u01/dumps
-Xlog:gc*:file=/u01/logs/gc-%t.log:time,uptime,level,tags:filecount=10,filesize=20M
-Djava.net.preferIPv4Stack=true

৯.২ WebLogic-নির্দিষ্ট Tuning

• Self-Tuning Thread Pool: WebLogic-কে thread পরিচালনা করতে দিন — নির্দিষ্ট প্রমাণ না থাকলে আগেভাগে tune করবেন না
• Work Manager priority: কম-অগ্রাধিকারের background কাজ সীমিত করুন
• Native IO Enabled
• Stuck Thread Detection: ডিফল্ট 600s — আগাম সতর্কতার জন্য 300s সেট করুন
• Domain Log Filter: সাধারণ warning-এর কোলাহল কমান
• Production Mode: সবসময় — কখনও প্রোডাকশন dev mode-এ চালাবেন না

৯.৩ সাধারণ Bottleneck

• JDBC pool exhaustion → অ্যাপ কোডে leaked connection
• Stuck thread → ধীর external service-এ blocking call
• OutOfMemoryError → memory leak, ছোট heap, বা PermGen/Metaspace
• Full GC pause → G1GC tuning বা বড় heap-এ যাওয়া

১০. Clustering ও Session Replication

high-availability web অ্যাপ্লিকেশনের জন্য session replication কনফিগার করুন। অপশন:

• In-Memory Replication: প্রতিটি session একটি backup server-এ কপি (ডিফল্ট)। সেরা পারফরম্যান্স।
• JDBC Persistence: session database-এ সংরক্ষিত। পূর্ণ cluster restart টিকে থাকে, ধীর।
• Coherence-based: সব সদস্য জুড়ে distributed cache। সবচেয়ে scalable।
• File-based: local file, কেবল single-machine cluster।

১১. নিরাপত্তা সেরা চর্চা

• ডিফল্ট port বদলান: 7001-এ AdminServer হ্যাকারের চুম্বক — 7901 বা অনুরূপ ব্যবহার করুন
• ইন্টারনেট-মুখী instance-এ Production Console নিষ্ক্রিয় করুন
• AdminConsole ও Node Manager-এর জন্য HTTPS সক্রিয় করুন
• Custom Identity / Custom Trust SSL keystore ব্যবহার করুন
• Authorization Provider-এর মাধ্যমে Role-based access (LDAP/AD ইন্টিগ্রেশন)
• ত্রৈমাসিক Critical Patch Update (CPU) প্রয়োগ করুন — WebLogic CVE ব্যাপকভাবে exploit করা হয়
• Network segmentation: Admin network পাবলিক ট্রাফিক থেকে আলাদা

এই তালিকার তিনটি বিষয় বাড়তি জোর পাওনা, কারণ মাঠপর্যায়ে এগুলোই বারবার ভুল অবস্থায় পাই। প্রথমত, t3 protocol — WebLogic-এর নিজস্ব RMI transport — Java ইতিহাসের সবচেয়ে খারাপ কিছু deserialization CVE বহন করেছে। admin host ছাড়া বাকি সবকিছুর জন্য firewall-এ t3/t3s ব্লক করুন, এবং একটি connection filter (weblogic.security.net.ConnectionFilterImpl) সেট করুন যাতে কেবল পরিচিত ঠিকানাই আদৌ t3-তে কথা বলতে পারে। শেষ ব্যবহারকারীদের HTTP লাগে; t3 তাদের কখনোই লাগে না।

দ্বিতীয়ত, demo certificate। প্রতিটি WebLogic install-এর সঙ্গে DemoIdentity ও DemoTrust keystore আসে, যার private key পৃথিবীর প্রতিটি WebLogic-এ অভিন্ন — এগুলো প্রকাশ্যে জানা। demo cert-এ থাকা একটি প্রোডাকশন server-এর encryption কেবল নামেই encryption। go-live-এর আগে Custom Identity/Custom Trust দিয়ে বদলান — কোনো ব্যতিক্রম নয়।

তৃতীয়ত, admin console। এটি তালাবদ্ধ করুন: AdminServer-কে কেবল-অভ্যন্তরীণ একটি address-এ bind করুন, administration port সক্রিয় করুন যাতে admin ট্রাফিক নিজস্ব SSL channel-এ চলে, আর console-কে কখনোই — কোনোভাবেই — ইন্টারনেট থেকে পৌঁছানোর মতো রাখবেন না; WebLogic CVE ক্যাটালগে এটিই সবচেয়ে বেশি scan হওয়া লক্ষ্য।

১২. WLST-এর মাধ্যমে সাধারণ Admin কাজ

# Connect
connect('weblogic','password','t3://adminhost:7001')

# Start/stop managed server
start('ms1','Server')
shutdown('ms1','Server')

# Roll cluster (one at a time)
shutdown('ms1','Server', ignoreSessions='false')
start('ms1','Server')

# Check status
domainRuntime()
cd('ServerRuntimes/ms1')
ls()
print cmo.getState()

# Thread dump
cd('/ServerRuntimes/ms1/JVMRuntime/ms1')
print cmo.getThreadStackTraces()

১৩. মনিটরিং ও ট্রাবলশুটিং

• WLDF (WebLogic Diagnostic Framework): policy + alert সহ অন্তর্নির্মিত মনিটরিং
• Enterprise Manager Cloud Control: একাধিক domain জুড়ে কেন্দ্রীভূত মনিটরিং
• যে log file জানা দরকার: AdminServer.log, ms<n>.log, nodemanager.log, access.log, GC log
• Thread dump: kill -3 <PID> বা WLST-এর মাধ্যমে — "server hung" সমস্যায় আপনার প্রথম টুল
• Heap dump: memory leak-এর জন্য Eclipse MAT দিয়ে বিশ্লেষণ করুন

১৩.১ Stuck Thread আসলে কী বোঝায়?

stuck thread হলো স্রেফ এমন একটি execute thread, যা কনফিগার করা threshold-এর — ডিফল্ট ৬০০ সেকেন্ড — চেয়ে বেশি সময় ধরে একটিমাত্র request প্রক্রিয়া করছে। WebLogic বলছে না thread-টি ভেঙে গেছে; বলছে "এই request-টি অনেক আগেই শেষ হওয়ার কথা ছিল।" thread-টি প্রায় সবসময়ই বাইরের কিছুর জন্য অপেক্ষা করছে: একটি ধীর SQL, একটি খালি connection pool, উত্তর দেওয়া বন্ধ করা remote service, বা অ্যাপ্লিকেশনের একটি lock। stuck-thread warning হলো ধোঁয়ার alarm, আগুন নয়।

কেন গুরুত্ব দিতেই হবে: stuck thread জমতে থাকে। প্রতিটি self-tuning pool-এ একটি slot স্থায়ীভাবে দখল করে, আর যথেষ্ট জমে গেলে WebLogic server-টিকে FAILED চিহ্নিত করে — এবং failure-এ restart করার জন্য Node Manager সেট থাকলে, আপনার server ভরদুপুরের ব্যবসার মাঝখানে bounce করে। একটিমাত্র ঝুলে যাওয়া external web-service call-কে এভাবে একটি পুরো cluster নামিয়ে দিতে দেখেছি — একবারে এক সদস্য করে।

১৩.২ আমার ExecuteThread বিশ্লেষণ রুটিন

server log-এ <BEA-000337> stuck-thread warning দেখা দিলে আমি ঠিক এটাই করি:

• ৩০ সেকেন্ড ব্যবধানে তিনটি thread dump নিই (jstack <PID> বা kill -3)। একটি dump দেখায় একটি মুহূর্ত; তিনটি দেখায় thread-টি সত্যিই আটকে আছে, নাকি শুধু ধীর।
• STUCK grep করে প্রতিটি stuck ExecuteThread-এর stack ওপর থেকে নিচে পড়ি: ওপরের frame-গুলো বলে এই মুহূর্তে কীসের জন্য অপেক্ষা, নিচের frame-গুলো বলে কোন অ্যাপ্লিকেশন entry point তাকে সেখানে এনেছে।
• ওপরের frame-টা pattern-match করি: socketRead0 মানে remote service বা database উত্তর দিচ্ছে না; oracle.jdbc frame মানে ধীর query — ডেটাবেজের দিক থেকে SQL-টা টেনে আনুন; ResourcePool.reserveResource মানে connection pool শেষ (সেকশন ৬.৪ দেখুন); অনেক thread জুড়ে একই monitor-এ waiting to lock মানে অ্যাপ্লিকেশন lock contention।
• কতগুলো thread একই stack শেয়ার করছে গুনি। বিশটি অভিন্ন stack মানে বিশটি সমস্যা নয় — একটি root cause, বিশটি শিকার।
• কারণ ঠিক করি, তারপর alarm সমন্বয় করি: stuck-thread detection ৩০০ সেকেন্ডে সেট করি, যাতে ব্যবস্থা নেওয়ার সময় থাকতেই warning পাই, আর সত্যিকারের দীর্ঘ কাজগুলো (report, batch) নিজস্ব Work Manager-এ রাখি যাতে সেগুলো কখনও alarm-ই না বাজায়।

১৪. WebLogic + Oracle Database = একসঙ্গে ভালো

WebLogic Oracle Database-এর সঙ্গে কথা বলার জন্য বিশেষভাবে তৈরি। মূল ইন্টিগ্রেশন:

• RAC-এর জন্য Active GridLink Data Source (FAN event, runtime LB)
• in-flight transaction failover-এর জন্য Transparent Application Continuity (TAC)
• ব্যর্থ operation replay-এর জন্য Application Continuity (AC)
• distributed caching-এর জন্য Oracle Coherence
• Oracle-এর জন্য tuned JDBC Statement Caching

১৫. WebLogic Patch করা

ত্রৈমাসিক CPU (Critical Patch Update) ও PSU (Patch Set Update)। OPatch-এর মাধ্যমে প্রয়োগ করুন:

cd $ORACLE_HOME/OPatch
./opatch lsinventory
./opatch apply /path/to/patch/12345678
./opatch lsinventory | grep 12345678

binary patch করার আগে সবসময় সব server (Admin + Managed + Node Manager) বন্ধ করুন। আগে non-prod-এ পরীক্ষা করুন।

১৬. প্রোডাকশন সেরা চর্চার সারসংক্ষেপ

• Production mode সক্রিয়। সবসময়।
• নিবেদিত host বা VM-এ AdminServer, বিচ্ছিন্ন network
• cluster-এ managed server, একাধিক machine, load balancer-এর পেছনে
• auto-restart-এর জন্য কনফিগার করা Node Manager
• RAC-এর জন্য JDBC Active GridLink
• GC log + JFR (Java Flight Recorder) সক্রিয়
• OOM-এ heap ও thread dump
• proactive alerting-এর জন্য WLDF policy
• SSL সর্বত্র — Admin Console, Node Manager, inter-server
• ত্রৈমাসিক CPU patching
• ত্রৈমাসিক DR drill
• সাধারণ পরিস্থিতির জন্য ডকুমেন্টেড runbook

১৭. আমার WebLogic Health-Check রুটিন

এই রুটিনটাই আমি প্রোডাকশন domain-এ সত্যিই চালাই — শান্ত estate-এ সাপ্তাহিক, ব্যস্তগুলোয় দৈনিক। WLST সংগ্রহের কাজ করলে লাগে মিনিট বিশেক, আর আমার ব্যবহার করা যেকোনো মনিটরিং ড্যাশবোর্ডের চেয়ে এটি বেশি ঘনীভূত-হতে-থাকা incident ধরেছে:

1. Server state: প্রতিটি managed server RUNNING, এবং health OK — শুধু "up" নয়। WARNING state-এ থাকা একটি server ইতিমধ্যেই আপনাকে কিছু বলেছে।
2. Stuck thread: গত ৭ দিনের server log-এ BEA-000337 grep করুন। নিজে-নিজে সেরে যাওয়া stuck thread-ও graph করার মতো একটি trend।
3. JDBC pool: প্রতি datasource-এ Active Connections High Count বনাম Maximum Capacity, সঙ্গে Waiting For Connection সংখ্যা। high-water ৮০%-এর ওপরে মানে ছাদ কাছে।
4. Heap trend: GC log-এ full-GC-এর হার ও heap-after-GC দেখুন। সপ্তাহে সপ্তাহে চড়তে থাকা heap-এর মেঝে হলো আগেভাগে নিজের কথা জানান দেওয়া একটি memory leak।
5. JMS backlog: প্রতিটি destination-এ queue depth ও oldest-message age। যে queue কেবলই বাড়ে, তার মানে একটি মৃত consumer।
6. Transaction health: JTA rollback ও timeout সংখ্যা — বাড়তে থাকা abandoned-transaction সংখ্যা প্রায়ই একটি ধুঁকতে থাকা resource-এর দিকে ইঙ্গিত করে।
7. Log sweep: গত পরীক্ষার পর AdminServer, managed server, Node Manager ও OHS log-এ নতুন Error/Critical এন্ট্রি।
8. Disk ও certificate: log filesystem-এর জায়গা, আর keystore-এর প্রতিটি SSL certificate-এর বাকি দিন। মেয়াদোত্তীর্ণ cert middleware-এর সবচেয়ে বোকা outage-গুলোর কারণ।
9. Patch posture: opatch lsinventory বনাম সর্বশেষ CPU — auditor (বা আক্রমণকারী) জানার আগে নিজের ফাঁকটা জানুন।
10. Failover প্রমাণ: ত্রৈমাসিক, maintenance window-তে ইচ্ছা করে একটি managed server মেরে দেখুন session-গুলো migrate করছে কি না। কখনও পরীক্ষা না করা failover একটি আশা, ডিজাইন নয়।

১৮. কখন WebLogic ব্যবহার করবেন না

এবার সততার পালা, কারণ যে কনসালট্যান্ট সবকিছুর জন্য WebLogic সুপারিশ করে, সে লাইসেন্স বেচছে, আর্কিটেকচার নয়। ২০২৬ সালে বেশিরভাগ নতুন অ্যাপ্লিকেশনের জন্য WebLogic ভুল উত্তর।

আপনি যদি একটি নতুন web অ্যাপ্লিকেশন বা একগুচ্ছ REST service বানাচ্ছেন, embedded Tomcat-এ Spring Boot আপনাকে দেয় একটি স্বয়ংসম্পূর্ণ artifact, একটি ফ্রি runtime, বিশাল একটি talent pool, আর এমন একটি আকার যা container ও CI/CD-তে স্বাভাবিকভাবে খাপ খায়। দরকারি কিছুই হারাবেন না, কারণ distributed EJB transaction বা replicated stateful session আপনার কখনও দরকারই ছিল না — আধুনিক ডিজাইন এমনিতেই state রাখে database বা cache-এ।

যেখানে WebLogic এখনও সঠিক পছন্দ: Oracle যা কেবল WebLogic-এ certify করে (Forms/Reports, EBS, SOA Suite), যেসব বিদ্যমান Java EE estate নতুন করে লেখার পক্ষে অতি বৃহৎ বা অতি নিয়ন্ত্রিত, এবং যেসব সিস্টেম সত্যিই XA transaction, WebLogic JMS বা RAC-এর বিপরীতে Active GridLink-এর ওপর ভর করে। ক্লায়েন্টদের জন্য আমার নিয়ম এক বাক্যে: যেখানে বাধ্য, সেখানে WebLogic চালান; বাকি সর্বত্র হালকা কিছু — আর এই দুই শ্রেণিকে ঘোলাটে হতে দেবেন না। Tomcat যে অ্যাপ্লিকেশন serve করতে পারত, তা host করতে WebLogic-এর লাইসেন্স ও প্রশাসন খরচ দেওয়া মানে টাকায় আগুন দেওয়া।

সাধারণ জিজ্ঞাসা (FAQ)

২০২৬ সালেও কি WebLogic প্রাসঙ্গিক?

হ্যাঁ — একটি নির্দিষ্ট শ্রেণির workload-এর জন্য। Oracle Forms ও Reports, E-Business Suite, SOA Suite এবং ব্যাংকিং, ফার্মা ও টেলিকমের হাজারো কাস্টম Java EE অ্যাপ্লিকেশন কেবল WebLogic-এই চলে, এবং সেই সিস্টেমগুলো আরও এক দশক প্রোডাকশনে থাকবে। যা বদলেছে তা হলো — নতুন অ্যাপ্লিকেশন আর প্রায় কেউই WebLogic দিয়ে শুরু করে না; আজকের চাহিদা এমন মানুষের, যারা বিদ্যমান estate পরিচালনা, tune ও নিরাপদ করতে পারে।

WebLogic ও Tomcat-এর মধ্যে পার্থক্য কী?

Tomcat একটি servlet container — এটি web অ্যাপ্লিকেশন চালায়, এর বেশি কিছু নয়। WebLogic একটি পূর্ণাঙ্গ Java EE অ্যাপ্লিকেশন সার্ভার: session replication সহ clustering, distributed JMS messaging, distributed transaction (XA), RAC-এর জন্য Active GridLink, একটি management console, WLST scripting এবং Oracle support। আপনার অ্যাপ্লিকেশনের যদি কেবল servlet আর একটি datasource দরকার হয়, Tomcat বা Spring Boot সহজতর ও ফ্রি। এন্টারপ্রাইজ যন্ত্রপাতি দরকার হলে WebLogic তার লাইসেন্সের মূল্য অর্জন করে।

WebLogic-এ stuck thread কী?

stuck thread হলো এমন একটি execute thread যা কনফিগার করা threshold-এর (ডিফল্ট ৬০০ সেকেন্ড) চেয়ে বেশি সময় ধরে একটিমাত্র request নিয়ে কাজ করছে। এটি উপসর্গ, রোগ নয় — thread-টি প্রায় সবসময়ই বাইরের কিছুর জন্য অপেক্ষা করছে: একটি ধীর SQL statement, শুকিয়ে যাওয়া JDBC connection pool, উত্তর দেওয়া বন্ধ করা remote web service, বা অ্যাপ্লিকেশনের ভেতরের একটি lock। একটি thread dump ঠিকঠাক দেখিয়ে দেয় প্রতিটি stuck thread কীসের জন্য অপেক্ষা করছে।

একটি WebLogic managed server-কে কতটা heap দেওয়া উচিত?

কোনো সর্বজনীন সংখ্যা নেই — মাপুন, তারপর size ঠিক করুন। আপনার GC log থেকে শুরু করুন: full GC-এর পরে heap যদি maximum-এর ৬০-৭০%-এর ওপরে থাকে, আপনার heap ছোট। Forms/Reports workload-এ আমি সাধারণত প্রতি managed server-এ 2 GB থেকে 8 GB-এর মধ্যে থাকি; বড় কাস্টম Java EE অ্যাপে G1GC সহ 16 GB যুক্তিসঙ্গত হতে পারে। সবসময় -Xms-কে -Xmx-এর সমান রাখুন, এবং মনে রাখবেন collector tune না করলে বড় heap মানে দীর্ঘতর GC pause।

মনিটরিংয়ের জন্য কি WebLogic admin console-ই যথেষ্ট?

না। console কেবল বর্তমান মুহূর্ত দেখায় — রাত ২টায় কী ঘটেছিল তা বলতে পারে না, pool শেষ হওয়ার আগে সতর্কও করতে পারে না। প্রোডাকশন মনিটরিংয়ে ন্যূনতম দরকার: GC log সবসময় চালু, heap ও stuck-thread alert-এর জন্য WLDF policy, JDBC pool ও thread-pool metric-গুলো ফাইল বা মনিটরিং সিস্টেমে টেনে আনা একটি WLST script, এবং server log-এর জন্য log shipping। console তদন্তের জন্য, শনাক্তকরণের জন্য নয়।

WebLogic কত ঘন ঘন patch করা উচিত?

ত্রৈমাসিক, Oracle-এর Critical Patch Update চক্রের সঙ্গে মিলিয়ে — জানুয়ারি, এপ্রিল, জুলাই, অক্টোবর। middleware জগতে WebLogic CVE সবচেয়ে সক্রিয়ভাবে exploit হওয়াগুলোর অন্যতম, বিশেষত t3 protocol বা console ছুঁয়ে যাওয়া যেকোনো কিছু। binary-তে OPatch দিয়ে PSU প্রয়োগ করুন, আগে non-production-এ পরীক্ষা করুন, এবং outage এড়াতে cluster-এ একবারে একটি server করে roll করুন।

শেষ কথা

Oracle WebLogic Server দুই দশকেরও বেশি সময় ধরে যথার্থ কারণেই পছন্দের এন্টারপ্রাইজ Java অ্যাপ্লিকেশন সার্ভার — এটি পরিণত, scalable, নিরাপদ এবং Oracle Database-এর সঙ্গে দৃঢ়ভাবে সংহত। হ্যাঁ, cloud-native জগৎ microservice ও Kubernetes-এর দিকে এগোচ্ছে, কিন্তু transactional, নিয়ন্ত্রিত, mission-critical Java অ্যাপ্লিকেশনের জন্য WebLogic অতুলনীয় থেকে গেছে। WebLogic ভালোভাবে আর্কিটেক্ট ও পরিচালনার দক্ষতা ক্রমেই দুর্লভ — এবং ক্রমেই মূল্যবান।

আপনার প্রতিষ্ঠান যদি WebLogic চালায় — নতুন domain setup, performance tuning, Active GridLink-এর মাধ্যমে RAC ইন্টিগ্রেশন, নিরাপত্তা hardening, সংস্করণ আপগ্রেড, বা একটি একগুঁয়ে প্রোডাকশন সমস্যার ট্রাবলশুটিং যা-ই দরকার হোক — আমি সাহায্য করতে চাই। বাংলাদেশ ও বিশ্বজুড়ে সফটওয়্যার প্রতিষ্ঠান, ব্যাংক, ফার্মা অপারেশন ও ট্রেডিং হাউসের জন্য আমি WebLogic পরিবেশ পরিচালনা করেছি এবং প্রতিটি কাজে গভীর ব্যবহারিক অভিজ্ঞতা নিয়ে আসি।

সম্পর্কিত লেখা